Operations | Monitoring | ITSM | DevOps | Cloud

When applications are deployed in the production environment, developers expect them to work smoothly without any performance issues. However, applications often experience unexpected bottlenecks, making it crucial to monitor applications. One of the simplest ways to monitor a C# application is to emit, save, and index log data for search, analysis, and troubleshooting. We’ll discuss how you can monitor your applications while making the most of C# logging.

Earlier this year Python 2 entered End of Life — and Splunk has already released versions of Splunk Cloud and Splunk Enterprise that provide a Python 3 runtime. As the developer of an app that is published to Splunkbase, if your app contains Python code, you need to update it to work with Python 3 and Splunk Enterprise 8.0 by July 1, 2020 as the Splunk Enterprise and Splunk Cloud releases after that date will no longer support the Python 2 runtime.

Even with tough economic times, e-commerce is up 25% since the beginning of March. But, fraud has increased as well; according to Malwarebytes online credit card skimming has increased by 26% in March alone. In our April “Staff Picks for Splunk Security Reading” blog post, I referenced a story about an e-commerce site getting hacked with a “virtual card skimmer” (thanks Matthew Joseff for sharing this with me).

Platforms like Heroku give you the freedom to focus on building great applications rather than getting lost setting up and maintaining infrastructure. One of the many great features of working with it is the Heroku logs that enable monitoring your stack error troubleshooting. It helps speed up the process when things go wrong. In this Heroku tutorial, we’ll uncover best practices for making the most of Heroku logs.

Logs are an invaluable source of information, as they provide insights into the severity and possible root causes of problems in your system. But it can be hard to get the right level of visibility from your logs while keeping costs to a minimum. Systems that process large volumes of logs consume more resources and therefore make up a higher percentage of your overall monitoring budget. Further, log throughput can be highly variable, creating unexpected resource usage and financial costs.

We’ve heard from our customers that you need visibility into metrics and logs from Google Cloud, other clouds, and on-prem in one place. Google Cloud has partnered with Blue Medora to bring you a single solution to save time and money in managing your logs in a single place. Google Cloud’s operations management suite gives you the same scalable core platform that powers all internal and Google Cloud observability.

What I love about our free and open Elastic SIEM is how easy it is to add new data sources. I’ve learned how to do this firsthand, and thought it’d be helpful to share my experience getting started. Last October, I joined Elastic Security when Elastic and Endgame combined forces. Working with our awesome security community, I’ve had the opportunity to add new data sources for our users to complement our growing catalog of integrations.

AWS Lambda is the leading serverless computing solution and is one of AWS’ most successful products, to date. Its popularity is in large part because of the way it makes development easier and faster. Lambda completely abstracts away the maintenance of underlying infrastructure including compute, storage, memory, and networking. Developers simply upload their code in the form of Lambda functions and the service fully handles the execution of these functions.

Monitoring all DNS requests in your network, including those that were blocked by (e.g., by a firewall) is a great way to increase visibility, enforce compliance and detect threats. A common problem with collecting DNS logs is that DNS server logs are notoriously hard to parse. Also, parsing only the logs of your DNS servers leaves a blind spot when it comes to usage of, or the attempt to use, an external DNS server like Google's 8.8.8.8.