Prometheus Monitoring

Achieve full visibility into highly dynamic container-based environments by integrating Prometheus into your application performance monitoring strategy.

What is Prometheus monitoring?

Prometheus is an open source Cloud Native Computing Foundation (CNCF) project that is highly scalable and integrates easily into container metrics, making it a popular choice among Kubernetes users. With powerful query language, accurate alerting, and a dedicated time-series database, Prometheus monitoring uses a multi-functional data model that enhances query functionalities and aggregates information and events. 

The growing popularity of highly dynamic service-oriented architectures has had a negative impact on visibility, making Prometheus monitoring a valuable solution for monitoring and management. 

What are the pros and cons of using Prometheus with Kubernetes?

Prometheus is unique partly due to its pull-based architecture, meaning that the Prometheus server queries data sources at regular intervals and pulls metrics from services rather than pushing metrics to the monitoring solution. Consequently, Prometheus is highly dependent on metric exporters, which can exist as stand-alone applications or are integrated into your application via client libraries such as APM solutions. 

Advantages of using Prometheus with Kubernetes include: 

  • Easy integration with Kubernetes since it uses service discovery and collects metrics on those services through their Prometheus defined endpoints.

  • Operational simplicity due to open source projects like the Prometheus operator and community-developed exporters. Prometheus is also currently limited to using a single node, reducing complexity and limiting potential failure modes.

  • A standardized approach that includes aggregating time-series data, which simplifies data collection and expands query functionality. 

  • Improved alerting through Alertmanager, which reduces MTTR with timely notifications that aid in identifying performance issues before users are affected.

  • Easy-to-learn query language (Prometheus's PromQL) and API. 

However, there are also disadvantages that result from the simplicity of Prometheus, including the following: 

  • Although using a single node reduces complexity, it also limits the range of metrics that can be monitored. 

  • The standardized method of collecting data based on time series creates a data model that may be missing contextual information which could be helpful.

  • Ensuring that all metric endpoints can be reached by the Prometheus poller creates the need for a more complicated secure network configuration. 

  • Additional tools are necessary for log management, long-term storage, user management, and dashboarding. Grafana is often recommended to create a visual dashboard, which can make initial set-up more complicated.

Best practices for Prometheus monitoring

Achieve better visibility and get the full range of benefits from Prometheus monitoring by creating and implementing a strategy that includes the following best practices: 

Understand metrics and when to use them

Prometheus has four metric types, and knowing when to use them improves accuracy and provides better contextual awareness. 

  • Counter: Measures quantity at the start of an event or counts a number of events. 

  • Gauge: Measures positive and negative changes, which is particularly helpful as it relates to time-based values such as memory use, requests in progress, or temperature.  

  • Histogram: Helps aggregate data by sampling and categorizing events with a sum of collected values. 

  • Summary: Similar to the histogram metric, but it can also calculate over a range of time by using total event counts and sums of observed values.

Choose the best exporter 

Although they all provide a similar service, choosing the most appropriate Prometheus exporter for your project can be instrumental in the success of your monitoring strategy. Research available exporters to evaluate how each handles the metrics most relevant to your application and gauge the quality of the project, based on its developer, recent updates, and user reviews.

Label carefully  

Check your exporter documentation for suggestions on how to label metrics so that they provide context, and establish consistent formatting protocol around label creation. Being able to customize and define your data is valuable, but remember that each created label set uses resources, which can become problematic on a larger scale. Try to keep metric labels to 10 or fewer to reduce overall resource costs. 

Set actionable alerts

Having a well-defined alerting strategy is key to effective performance monitoring. Determine which metrics or events are critical to monitor, set them at a reasonable threshold to catch issues before they affect end-users without causing alert fatigue for your IT staff, and make sure notifications are set-up to reach the right team in a timely manner. 

 

How AppDynamics Helps

Collecting data is only one piece of the performance monitoring puzzle; the ability to visualize and analyze the data efficiently is essential to its value. One of the primary downsides to microservices-based architecture is the abundance of data from each component and determining how to view and share it effectively. 

AppDynamics simplifies visibility by creating a single source of truth that consolidates the various elements of your tech stack into a customizable, production-grade dashboard that provides a unified and comprehensive perspective of your architecture, application performance, user journeys, and business outcomes.

 

“We can see everything inside both our dynamic container infrastructure and the microservices running inside the containers. AppDynamics gives us unprecedented insight.”

Philippe Dono, Head of the Core Platform and Performance Team, Privalia



Agents of Transformation 2021: The rise of full-stack observability

Learn how technologists can manage soaring IT complexity by connecting full-stack observability with business context.




See your applications like you never have before