Introduction​

Your business depends on the reliability of the third-party services you use. Monitoring the status pages of these services is the best way of keeping track of their outages and maintenances. Although some status pages let you subscribe to alerts, there is no standard way of doing this. Service providers can change their status page providers, disable subscriptions, or not support the same notification options.

A status page aggregator is a tool that solves all these problems by aggregating the status pages of multiple services in one place. If you depend on only 2-3 third-party services, you can probably get away without a status page aggregator. Beyond this, it will become harder to stay on top of third-party service outages and maintenances, leaving gaps in your monitoring.

Let's look at the top 6 reasons why you need a status page aggregator.

Introduction​

IncidentHub has many integrations to receive alerts. You can choose from Slack, Webhook, Email, Discord, PagerDuty, and more. In this article, we will explore how to receive IncidentHub alerts in your webhooks.

• Introduction
• What are Webhooks?
• Using Webhooks For IncidentHub Alerts
  • Integrating Your Webhook
  • Testing your Webhook
  • The Webhook payload format
  • Webhook Security
  • Webhook Errors
• Best Practices
• Conclusion
• FAQ

What are Webhooks?​

Introduction​

For the last two months, we have focused on improving the onboarding experience for users so that they can get started with monitoring with minimal effort. We have also added several improvements in the backend to make the service more robust and reliable. Some of the usability improvements are driven by user feedback. Others incorporate what we would personally like to see in such a monitoring service. We have also improved the dashboard user experience.

• Introduction
• Easier onboarding
  • Service Component Autodetection
  • Commonly Used Services
  • Test Channels
• Dashboard Improvements
  • Services With Incidents
• Reliability Improvements
  • Alert Emails for Webhook Failures
  • Bug Fixes and Robustness Improvements

Introduction​

This article is part of a series on setting up an end-to-end monitoring and alerting stack using Prometheus.

Continuing our series on setting Prometheus in a Docker container, we will add a Grafana instance to our Prometheus setup.

Please refer to the previous article where we use docker compose to run Prometheus and Alertmanager together as that forms the basis to run multiple related containers. We will add a container to run Grafana to the same compose file in this article.

• Introduction
• Adding a Grafana Container to our Docker Compose
• Adding a Dashboard
• Troubleshooting
  • My datasource "Save and Test" fails
  • I cannot see any data in my dashboard
  • Only some of the panels in my dashboard show data
  • If I restart my containers, the dashboard is gone
• Conclusion
• References

Introduction​

A status page forms a key part of your incident communication strategy. When it comes to setting up a status page, you have two options:

• Host your own - using either an open source project or a custom solution.
• Use a managed status page provider.

We will examine the pros and cons of each option along these dimensions:

1. Feature Set
2. Service Related

For 1, if you choose a self-managed, open-source or custom solution, it's in your control. For a managed solution, you are limited by the provider's feature set.

For 2, if you choose a self-managed solution, your team is responsible for the quality of the service. For a managed solution, you are dependent on the provider's service quality.

In most cases, you are better off using a managed solution from a reputed provider, unless you have:

• Specific requirements that are not met by the vendor.
• Budget constraints.

Introduction​

If you manage applications running on cloud platforms, you likely depend on multiple cloud vendors and services. These could be infrastructure providers like AWS, GCP or Azure. A vulnerability in any of these services could potentially impact your applications and your users.

A cloud platform has many moving parts, many of which are dependent on other third-party providers. For example:

• Operating system images for VMs which are maintained by third-party vendors.
• Container images which are hosted on external repositories.
• Software stacks which are maintained by other vendors but available for deployment on the cloud provider.
• Libraries used by the cloud provider's internal software which are maintained by other developers or organizations.
• Control plane software like Kubernetes.
• Hardware, like processors, which are provided by the manufacturer.
• Hypervisors which are developed and maintained by third-party vendors.
• Networking hardware manufactured by other vendors.

Introduction​

This article is part of a series on setting up an end-to-end monitoring and alerting stack using Prometheus.

Continuing our series on setting up Prometheus in a container, this article provides a step-by-step guide for how to configure alerts in Prometheus. We will add alerting rules and deploy Prometheus Alertmanager with Slack integration.

If you follow the steps in this article, you will end up with a containerized setup for:

1. A Prometheus instance with alerting rules.
2. An Alertmanager instance which can send alerts originating from those rules to a Slack channel.

Let's get started.

Introduction​

This article is part of a series on setting up an end-to-end monitoring and alerting stack using Prometheus.

There are different ways you can use to deploy the Prometheus monitoring tool in your environment. One of the fastest ways to get started is to deploy it as a Docker container. This guide shows you how to quickly set up a minimal Prometheus on your laptop. You can then extend that setup to add a monitoring dashboard, alerting, and authentication.

• Introduction
• Deploying Prometheus in a Docker Container
  • Basic Setup
    • Useful Tip
  • Separating the Configuration
  • Making the Data Storage Persistent
  • Further Configuration
• Conclusion
• References

Deploying Prometheus in a Docker Container​

Basic Setup​

Running Prometheus in Docker is very simple using this command

docker run -p 9000:9090 prometheus prom/prometheus:v3.0.0

This will pull and run the latest version (as of this writing) of Prometheus. You can access the Prometheus UI at localhost:9000. Note that the container port 9090 is forwarded to the localhost port 9000.

Introduction​

This article is an attempt to list the best incident management material and guides available for free on the internet. If I've missed something you think should be here, do let me know and I'll be happy to add it.

• Introduction
• Reading Material (Articles, Guides, Slides, Books)
• Templates and Real-World Examples
• Conference Talks
• Podcast Episodes

Introduction​

This article is part of a series on setting up an end-to-end monitoring and alerting stack using Prometheus.

The Prometheus monitoring tool can store its metrics either locally or remotely. You can configure a remote data store using the remote_write configuration. This article describes the various data store options available as well as how to set up a remote store.

Overview of Remote Storage​

By default, Prometheus stores data locally wherever it is installed. The data directory can be configured by using the --storage.tsdb.path command line option when starting Prometheus. In practice you can use a separate disk for higher performance attached to the machine where Prometheus is running.

However, this may not be possible or optimal in all situations as you might want a data store that is more suited for time series data, and has larger storage capabilities for higher data retention. Prometheus would usually run in a standalone VM or a Kubernetes pod or a Docker container, and it would not have access to such data stores by default.

A remote store can add these capabilities to Prometheus. The remote storage option can be set by using the remote_write key in the Prometheus configuration YAML file.