One place for hosting & domains


      Exploring the Features of Intelligent Monitoring, powered by INAP INblue

      What would you do if you didn’t have to spend time on routine server- or cloud-related maintenance and monitoring?

      According to INAP’s The State of IT infrastructure Management report, a vast majority of IT professionals say they are not spending enough time designing or implementing new solutions, working on expansions or upgrades, or focusing on information security projects. As it stands, 25 percent of participants say they spend too many hours on monitoring, and it’s clear that there’s a desire to set aside the busywork for value-added projects, allowing IT to be a center for innovation, rather than viewed as “purely keeping the lights on” by the company’s senior management.

      Intelligent Monitoring, powered by INAP INblue—a multicloud infrastructure management platform, gives you time for what matters. It’s a premium managed cloud and monitoring service—available today for INAP Bare Metal customers—that raises the bar for managed hosting solutions by ensuring proactive support, service transparency and consistent performance.

      “Infrastructure monitoring strategies are only as good as the actions that follow alerts,” said Jennifer Curry, SVP of Global Cloud Services at INAP. “We built Intelligent Monitoring to not only improve cloud performance and availability, but to set a new benchmark for managed services transparency.”

      In addition to an improved service experience, Managed Bare Metal customers also have access to the same enterprise-grade monitoring and management tools used by INAP technicians, offering functionality and control that will eliminate the need for customers to invest in third-party remote monitoring and management solutions, including remote execution and scripting, unified log management, patch management and automation, and port, service and URL monitoring.

      Let’s take a closer look at the features that make Intelligent Monitoring a one-of-a-kind solution.

      Advanced Monitoring & Action Items

      Built from the ground up with leading technologies like SaltStack and Elastic Beats, the Intelligent Monitoring agent tracks everything from server resource usage to Apache and MySQL connections. The in-depth, proprietary monitoring technology is installed directly onto your server, enabling INAP technicians to respond to alerts before performance degrading issues arise. Default trigger thresholds are chosen by INAP’s support team based on years of data and first-hand expertise. You have full access to all monitoring metrics and can request custom alert triggers, or modifications to trigger thresholds.

      When you log into INblue, the dashboard will give you a snapshot of your server environment through system events called Action Items. If you subscribe to the fully managed Service First edition, these items allow your INAP support team to proactively manage your environment and rapidly respond to alerts. Action Items are triggered in a variety of ways, including when infrastructure or network monitoring thresholds are surpassed, when a critical service shuts down or when a new software patch becomes available.

      Action Items

      Support Remediation Aided by Smart Workflow System

      INAP technicians remediate Action Items using our proprietary Smart Workflow System, which enables fast, accurate and consistent troubleshooting. Here’s a brief look how it works:

      1. The Smart Workflow System defines the Action Item type and initiates appropriate workflow process.
      2. The system automatically creates a support case for the Action Item, pulling historical correlated issue data, trigger metrics and detailed log info.
      3. Using the data and Action Item type, the assigned INAP Service First support technician investigates the issue following a branching series of software-defined and expert-tested remediation steps. Customers may request custom workflows for scenarios unique to their environment.
      4. Upon resolution of the Action Item, your assigned technician will notify you via the Action Item details page and include relevant root cause data.
      5. The Smart Workflow System constantly improves as new system data and insights from INAP experts modify issue definitions and remediation steps.

      On the other side of the glass, the INblue platform is your vehicle for ensuring absolute transparency. At the top of any Action Item details page, you’ll see the INAP technician assigned to the workflow, the current status of the event and tasks they are currently performing or have already performed. You can review information about correlated past issues, metric and log data pinpointing a trigger, and your full support history for any Action Item.

      However, for most Action Items, you won’t have to do a single thing. Intelligent Monitoring’s Smart Workflow System and the INAP Service First support team are on top of every case.

      Patching and Log Management

      Intelligent Monitoring radically simplifies two activities that most IT professionals consider especially tedious: patching and log management.

      The patching update process is streamlined, as all available patches for your server are proactively listed in groups. You can handle this process in one of two ways, depending on how much control you want. You can confirm and schedule the patch to complete the process with INAP support, or—if you want a hands-off approach—you can choose to auto-patch your server daily and your team will receive calendar invites for each scheduled patch.

      Intelligent Monitoring will also save you from manually browsing events by providing a chronological event log for all your servers. Easily filter by server and file path, or dive deep with a keyword search. You’ll be able to accelerate analysis and locate critical information. Plus, the log management feature provides your INAP technicians critical, actionable intelligence to keep your environment compliant and secure.

      Log Management

      Remote Execution and Scripting

      Intelligent Monitoring allows you to easily create and run remote execution scripts to any of your installed servers, giving you a single portal for taking control of your environment. You can choose from scripts you’ve already created and schedule them by inserting a token from your two-factor authentication application. You will automatically receive an email when the script successfully executes.

      If you want to create your own Bash or Powershell scripts, you can do so via the Script Editor, located in the side navigation of the INblue platform.

      Port, Service and URL Monitoring

      Under the Ports tab on any Server Details page, you can review, edit and monitor triggers for your server’s open and closed ports. Port Status changes will be shown in your Action Items list.

      Intelligent Monitoring also allows you to monitor any available services running on your system. You can also stop, start or restart services from the Services tab. For example, you can enable service monitoring on Chron Dee, enabling the auto-restart feature. With this monitoring feature enabled, you can rest assured that if a service ever fails, it will automatically create a new Action Item.

      Looking Ahead

      This is just the beginning for Intelligent Monitoring, powered by the INAP INblue platform. Many more features and capabilities are on the way, but in the meantime, we hope you enjoy exploring the tool and look forward to hearing your feedback.

      Demo INAP Intelligent Monitoring Today


      Laura Vietmeyer


      Source link

      Three Reasons Why We Built Intelligent Monitoring, Powered by INblue

      This week, we officially launched our premium managed cloud and monitoring service, Intelligent Monitoring. Powered by INAP’s new infrastructure and support platform, INblue, the service is an important milestone for our cloud business and one we expect to set new benchmarks for managed services transparency and support experience consistency.

      You can take a closer look at Intelligent Monitoring and its many great features in the video below or over at our product page. Today, however, I’d like to share some insight into why we developed Intelligent Monitoring, and why we think it will benefit the countless businesses who rely on service providers to enable meaningful IT transformations.

      1. To Retire the Concept of ‘Just Trust Us’ in Managed Hosting  

      We built Intelligent Monitoring because traditional managed hosting is stuck in an innovation rut.

      Automation transformed data center operations. It made networks faster. It made the cloud possible by pushing the limits of scalability. But there’s one item automation hasn’t yet cracked: the disjointed, opaque experience of working with a managed service provider after the infrastructure is online.

      Any managed infrastructure service inherently relies on the concept of “just trust us.” Hand over the keys to your critical infrastructure and hope the provider knows what they’re doing if something goes wrong. What too often results from this is a gauntlet of service-related pain points: reactive and inconsistent troubleshooting of regularly occurring issues, a rotating cast of anonymous technicians, unreliable response times, and the inability to see what is being done to the server or cloud environment and why.

      Intelligent Monitoring acknowledges that “just trust us” is no longer acceptable. The service combines the very best elements of advanced monitoring automation with a proactive, software-defined support experience that values transparency and consistency above all else.

      Here’s how it works. A lightweight and secure agent installed on your servers and VMs tracks virtually every aspect of the environment—hardware, resources, network, application metrics, available patches, open ports, etc.—in real time. If a monitoring threshold is triggered for subscribers of our managed cloud service, INAP technicians will respond to alerts before performance degrading issues arise. Tickets are created proactively, and issues are mitigated using a proprietary Smart Workflow System that assists our experts with finding accurate solutions.

      Better yet, customers will immediately know who on the INAP team is assigned to a task via the event’s unique Action Item page. From this single screen, users can track progress on the open task, communicate directly with the technician and view forensic information associated with the event using logs and data from correlated past issues.

      INblue Launch

      2. To Streamline the Actions That Follow Alerts 

      We built Intelligent Monitoring because an infrastructure management strategy is only as good as the actions that follow alerts.

      While there are plenty of standalone tools available for monitoring, patching and managing remotely hosted environments, they often take a significant amount of time to configure. Certain monitoring programs are limited to read-only outputs. Meaning, admins have to manually remediate identified issues or jump to separate tools to complete the job.

      Intelligent Monitoring and the INblue platform seamlessly integrate with customer server environments, allowing IT pros to not just keep tabs on the health of their infrastructure, but take control of it via a powerful toolkit that includes universal log management, patch automation, service controls, and remote execution and script management. With the INblue platform, users are also able to manage their accounts, provision new services, manage firewalls and reboot servers. By hosting with INAP, organizations will eliminate the need for many third-party tools.

      With Intelligent Monitoring, fully managed cloud customers will enjoy the backing of INAP’s Service First Support team. For the do-it-yourself IT admin, we also offer the Intelligent Monitoring toolkit for a low per-server cost. To compare our Service First and Insight editions, download the product overview guide. At launch, Intelligent Monitoring is optimized for Bare Metal customers. Multicloud functionality and support is on the way in future releases.

      3. To Help IT Pros Make Time for What Matters Most  

      Finally, the most important reason why we built Intelligent Monitoring: IT professionals want to be the centers of innovation at their organizations, but are too weighed down by time-intensive, routine infrastructure tasks to achieve that goal.

      Late last year, we interviewed 500 IT professionals about time spent on infrastructure upkeep. Unsurprisingly, the No. 1 task IT professionals spend too much time on is infrastructure monitoring. Additionally, a majority of respondents (52 percent) say the time it takes their teams to address critical patches and updates leaves their organizations exposed to security risks.

      While maintaining the performance and ensuring the security of infrastructure is critically important, our survey respondents acknowledged that the extent of the effort detracts from the broader mission of their job function. If hypothetically given back 16 hours of their week previously spent monitoring and troubleshooting infrastructure, IT pros said a majority of that time would be dedicated to activities like researching new tech, developing new apps and/or products, skill development and application performance optimization.

      Overall, 77 percent of IT professionals agreed they could “bring more value to my organization if I spent less time on routine tasks like server monitoring and maintenance.”

      We believe that Intelligent Monitoring and INAP Managed Bare Metal are just the vehicles for giving IT the time to make a truly value-added difference. I hope you’ll take a moment to see for yourself.

      Demo INAP Intelligent Monitoring Today


      Jennifer Curry
      • SVP, Global Cloud Services

      Jennifer Curry is SVP, Global Cloud Services. She is an operational and technology leader with over 17 years of experience in the IT industry, including seven years in the hosting/cloud market. READ MORE

      Source link

      How to Set Up a Prometheus, Grafana and Alertmanager Monitoring Stack on DigitalOcean Kubernetes


      Along with tracing and logging, monitoring and alerting are essential components of a Kubernetes observability stack. Setting up monitoring for your DigitalOcean Kubernetes cluster allows you to track your resource usage and analyze and debug application errors.

      A monitoring system usually consists of a time-series database that houses metric data and a visualization layer. In addition, an alerting layer creates and manages alerts, handing them off to integrations and external services as necessary. Finally, one or more components generate or expose the metric data that will be stored, visualized, and processed for alerts by the stack.

      One popular monitoring solution is the open-source Prometheus, Grafana, and Alertmanager stack, deployed alongside kube-state-metrics and node_exporter to expose cluster-level Kubernetes object metrics as well as machine-level metrics like CPU and memory usage.

      Rolling out this monitoring stack on a Kubernetes cluster requires configuring individual components, manifests, Prometheus metrics, and Grafana dashboards, which can take some time. The DigitalOcean Kubernetes Cluster Monitoring Quickstart, released by the DigitalOcean Community Developer Education team, contains fully defined manifests for a Prometheus-Grafana-Alertmanager cluster monitoring stack, as well as a set of preconfigured alerts and Grafana dashboards. It can help you get up and running quickly, and forms a solid foundation from which to build your observability stack.

      In this tutorial, we’ll deploy this preconfigured stack on DigitalOcean Kubernetes, access the Prometheus, Grafana, and Alertmanager interfaces, and describe how to customize it.


      Before you begin, you’ll need a DigitalOcean Kubernetes cluster available to you, and the following tools installed in your local development environment:

      • The kubectl command-line interface installed on your local machine and configured to connect to your cluster. You can read more about installing and configuring kubectl in its official documentation.
      • The git version control system installed on your local machine. To learn how to install git on Ubuntu 18.04, consult How To Install Git on Ubuntu 18.04.
      • The Coreutils base64 tool installed on your local machine. If you’re using a Linux machine, this will most likely already be installed. If you’re using OS X, you can use openssl base64, which comes installed by default.

      Note: The Cluster Monitoring Quickstart has only been tested on DigitalOcean Kubernetes clusters. To use the Quickstart with other Kubernetes clusters, some modification to the manifest files may be necessary.

      Step 1 — Cloning the GitHub Repository and Configuring Environment Variables

      To start, clone the DigitalOcean Kubernetes Cluster Monitoring GitHub repository onto your local machine using git:

      • git clone

      Then, navigate into the repo:

      You should see the following directory structure:


      LICENSE changes.txt manifest

      The manifest directory contains Kubernetes manifests for all of the monitoring stack components, including Service Accounts, Deployments, StatefulSets, ConfigMaps, etc. To learn more about these manifest files and how to configure them, skip ahead to Configuring the Monitoring Stack.

      If you just want to get things up and running, begin by setting the APP_INSTANCE_NAME and NAMESPACE environment variables, which will be used to configure a unique name for the stack's components and configure the Namespace into which the stack will be deployed:

      • export APP_INSTANCE_NAME=sammy-cluster-monitoring
      • export NAMESPACE=default

      In this tutorial, we set APP_INSTANCE_NAME to sammy-cluster-monitoring, which will prepend all of the monitoring stack Kubernetes object names. You should substitute in a unique descriptive prefix for your monitoring stack. We also set the Namespace to default. If you’d like to deploy the monitoring stack to a Namespace other than default, ensure that you first create it in your cluster:

      • kubectl create namespace "$NAMESPACE"

      You should see the following output:


      namespace/sammy created

      In this case, the NAMESPACE environment variable was set to sammy. Throughout the rest of the tutorial we'll assume that NAMESPACE has been set to default.

      Now, use the base64 command to base64-encode a secure Grafana password. Be sure to substitute a password of your choosing for your_grafana_password:

      • export GRAFANA_GENERATED_PASSWORD="$(echo -n 'your_grafana_password' | base64)"

      If you're using macOS, you can substitute the openssl base64 command which comes installed by default.

      At this point, you've grabbed the stack's Kubernetes manifests and configured the required environment variables, so you're now ready to substitute the configured variables into the Kubernetes manifest files and create the stack in your Kubernetes cluster.

      Step 2 — Creating the Monitoring Stack

      The DigitalOcean Kubernetes Monitoring Quickstart repo contains manifests for the following monitoring, scraping, and visualization components:

      • Prometheus is a time series database and monitoring tool that works by polling metrics endpoints and scraping and processing the data exposed by these endpoints. It allows you to query this data using PromQL, a time series data query language. Prometheus will be deployed into the cluster as a StatefulSet with 2 replicas that uses Persistent Volumes with DigitalOcean Block Storage. In addition, a preconfigured set of Prometheus Alerts, Rules, and Jobs will be stored as a ConfigMap. To learn more about these, skip ahead to the Prometheus section of Configuring the Monitoring Stack.
      • Alertmanager, usually deployed alongside Prometheus, forms the alerting layer of the stack, handling alerts generated by Prometheus and deduplicating, grouping, and routing them to integrations like email or PagerDuty. Alertmanager will be installed as a StatefulSet with 2 replicas. To learn more about Alertmanager, consult Alerting from the Prometheus docs.
      • Grafana is a data visualization and analytics tool that allows you to build dashboards and graphs for your metrics data. Grafana will be installed as a StatefulSet with one replica. In addition, a preconfigured set of Dashboards generated by kubernetes-mixin will be stored as a ConfigMap.
      • kube-state-metrics is an add-on agent that listens to the Kubernetes API server and generates metrics about the state of Kubernetes objects like Deployments and Pods. These metrics are served as plaintext on HTTP endpoints and consumed by Prometheus. kube-state-metrics will be installed as an auto-scalable Deployment with one replica.
      • node-exporter, a Prometheus exporter that runs on cluster nodes and provides OS and hardware metrics like CPU and memory usage to Prometheus. These metrics are also served as plaintext on HTTP endpoints and consumed by Prometheus. node-exporter will be installed as a DaemonSet.

      By default, along with scraping metrics generated by node-exporter, kube-state-metrics, and the other components listed above, Prometheus will be configured to scrape metrics from the following components:

      • kube-apiserver, the Kubernetes API server.
      • kubelet, the primary node agent that interacts with kube-apiserver to manage Pods and containers on a node.
      • cAdvisor, a node agent that discovers running containers and collects their CPU, memory, filesystem, and network usage metrics.

      To learn more about configuring these components and Prometheus scraping jobs, skip ahead to Configuring the Monitoring Stack. We'll now substitute the environment variables defined in the previous step into the repo's manifest files, and concatenate the individual manifests into a single master file.

      Begin by using awk and envsubst to fill in the APP_INSTANCE_NAME, NAMESPACE, and GRAFANA_GENERATED_PASSWORD variables in the repo's manifest files. After substituting in the variable values, the files will be combined and saved into a master manifest file called sammy-cluster-monitoring_manifest.yaml.

      • awk 'FNR==1 {print "---"}{print}' manifest/*
      • > "${APP_INSTANCE_NAME}_manifest.yaml"

      You should consider storing this file in version control so that you can track changes to the monitoring stack and roll back to previous versions. If you do this, be sure to scrub the admin-password variable from the file so that you don't check your Grafana password into version control.

      Now that you've generated the master manifest file, use kubectl apply -f to apply the manifest and create the stack in the Namespace you configured:

      • kubectl apply -f "${APP_INSTANCE_NAME}_manifest.yaml" --namespace "${NAMESPACE}"

      You should see output similar to the following:


      serviceaccount/alertmanager created configmap/sammy-cluster-monitoring-alertmanager-config created service/sammy-cluster-monitoring-alertmanager-operated created service/sammy-cluster-monitoring-alertmanager created . . . created configmap/sammy-cluster-monitoring-prometheus-config created service/sammy-cluster-monitoring-prometheus created statefulset.apps/sammy-cluster-monitoring-prometheus created

      You can track the stack’s deployment progress using kubectl get all. Once all of the stack components are RUNNING, you can access the preconfigured Grafana dashboards through the Grafana web interface.

      Step 3 — Accessing Grafana and Exploring Metrics Data

      The Grafana Service manifest exposes Grafana as a ClusterIP Service, which means that it's only accessible via a cluster-internal IP address. To access Grafana outside of your Kubernetes cluster, you can either use kubectl patch to update the Service in-place to a public-facing type like NodePort or LoadBalancer, or kubectl port-forward to forward a local port to a Grafana Pod port. In this tutorial we'll forward ports, so you can skip ahead to Forwarding a Local Port to Access the Grafana Service. The following section on exposing Grafana externally is included for reference purposes.

      Exposing the Grafana Service using a Load Balancer (optional)

      If you'd like to create a DigitalOcean Load Balancer for Grafana with an external public IP, use kubectl patch to update the existing Grafana Service in-place to the LoadBalancer Service type:

      • kubectl patch svc "$APP_INSTANCE_NAME-grafana"
      • --namespace "$NAMESPACE"
      • -p '{"spec": {"type": "LoadBalancer"}}'

      The kubectl patch command allows you to update Kubernetes objects in-place to make changes without having to re-deploy the objects. You can also modify the master manifest file directly, adding a type: LoadBalancer parameter to the Grafana Service spec. To learn more about kubectl patch and Kubernetes Service types, you can consult the Update API Objects in Place Using kubectl patch and Services resources in the official Kubernetes docs.

      After running the above command, you should see the following:


      service/sammy-cluster-monitoring-grafana patched

      It may take several minutes to create the Load Balancer and assign it a public IP. You can track its progress using the following command with the -w flag to watch for changes:

      • kubectl get service "$APP_INSTANCE_NAME-grafana" -w

      Once the DigitalOcean Load Balancer has been created and assigned an external IP address, you can fetch its external IP using the following commands:

      • SERVICE_IP=$(kubectl get svc $APP_INSTANCE_NAME-grafana
      • --namespace $NAMESPACE
      • --output jsonpath='{.status.loadBalancer.ingress[0].ip}')
      • echo "http://${SERVICE_IP}/"

      You can now access the Grafana UI by navigating to http://SERVICE_IP/.

      Forwarding a Local Port to Access the Grafana Service

      If you don't want to expose the Grafana Service externally, you can also forward local port 3000 into the cluster directly to a Grafana Pod using kubectl port-forward.

      • kubectl port-forward --namespace ${NAMESPACE} ${APP_INSTANCE_NAME}-grafana-0 3000

      You should see the following output:


      Forwarding from -> 3000 Forwarding from [::1]:3000 -> 3000

      This will forward local port 3000 to containerPort 3000 of the Grafana Pod sammy-cluster-monitoring-grafana-0. To learn more about forwarding ports into a Kubernetes cluster, consult Use Port Forwarding to Access Applications in a Cluster.

      Visit http://localhost:3000 in your web browser. You should see the following Grafana login page:

      Grafana Login Page

      To log in, use the default username admin (if you haven't modified the admin-user parameter), and the password you configured in Step 1.

      You'll be brought to the following Home Dashboard:

      Grafana Home Page

      In the left-hand navigation bar, select the Dashboards button, then click on Manage:

      Grafana Dashboard Tab

      You'll be brought to the following dashboard management interface, which lists the dashboards configured in the dashboards-configmap.yaml manifest:

      Grafana Dashboard List

      These dashboards are generated by kubernetes-mixin, an open-source project that allows you to create a standardized set of cluster monitoring Grafana dashboards and Prometheus alerts. To learn more, consult the kubernetes-mixin GitHub repo.

      Click in to the Kubernetes / Nodes dashboard, which visualizes CPU, memory, disk, and network usage for a given node:

      Grafana Nodes Dashboard

      Describing how to use these dashboards is outside of this tutorial’s scope, but you can consult the following resources to learn more:

      In the next step, we'll follow a similar process to connect to and explore the Prometheus monitoring system.

      Step 4 — Accessing Prometheus and Alertmanager

      To connect to the Prometheus Pods, we can use kubectl port-forward to forward a local port. If you’re done exploring Grafana, you can close the port-forward tunnel by hitting CTRL-C. Alternatively, you can open a new shell and create a new port-forward connection.

      Begin by listing running Pods in the default namespace:

      • kubectl get pod -n default

      You should see the following Pods:


      sammy-cluster-monitoring-alertmanager-0 1/1 Running 0 17m sammy-cluster-monitoring-alertmanager-1 1/1 Running 0 15m sammy-cluster-monitoring-grafana-0 1/1 Running 0 16m sammy-cluster-monitoring-kube-state-metrics-d68bb884-gmgxt 2/2 Running 0 16m sammy-cluster-monitoring-node-exporter-7hvb7 1/1 Running 0 16m sammy-cluster-monitoring-node-exporter-c2rvj 1/1 Running 0 16m sammy-cluster-monitoring-node-exporter-w8j74 1/1 Running 0 16m sammy-cluster-monitoring-prometheus-0 1/1 Running 0 16m sammy-cluster-monitoring-prometheus-1 1/1 Running 0 16m

      We are going to forward local port 9090 to port 9090 of the sammy-cluster-monitoring-prometheus-0 Pod:

      • kubectl port-forward --namespace ${NAMESPACE} sammy-cluster-monitoring-prometheus-0 9090

      You should see the following output:


      Forwarding from -> 9090 Forwarding from [::1]:9090 -> 9090

      This indicates that local port 9090 is being forwarded successfully to the Prometheus Pod.

      Visit http://localhost:9090 in your web browser. You should see the following Prometheus Graph page:

      Prometheus Graph Page

      From here you can use PromQL, the Prometheus query language, to select and aggregate time series metrics stored in its database. To learn more about PromQL, consult Querying Prometheus from the official Prometheus docs.

      In the Expression field, type kubelet_node_name and hit Execute. You should see a list of time series with the metric kubelet_node_name that reports the Nodes in your Kubernetes cluster. You can see which node generated the metric and which job scraped the metric in the metric labels:

      Prometheus Query Results

      Finally, in the top navigation bar, click on Status and then Targets to see the list of targets Prometheus has been configured to scrape. You should see a list of targets corresponding to the list of monitoring endpoints described at the beginning of Step 2.

      To learn more about Prometheus and how to query your cluster metrics, consult the official Prometheus docs.

      To connect to Alertmanager, which manages Alerts generated by Prometheus, we'll follow a similar process to what we used to connect to Prometheus. . In general, you can explore Alertmanager Alerts by clicking into Alerts in the Prometheus top navigation bar.

      To connect to the Alertmanager Pods, we will once again use kubectl port-forward to forward a local port. If you’re done exploring Prometheus, you can close the port-forward tunnel by hitting CTRL-Cor open a new shell to create a new connection. .

      We are going to forward local port 9093 to port 9093 of the sammy-cluster-monitoring-alertmanager-0 Pod:

      • kubectl port-forward --namespace ${NAMESPACE} sammy-cluster-monitoring-alertmanager-0 9093

      You should see the following output:


      Forwarding from -> 9093 Forwarding from [::1]:9093 -> 9093

      This indicates that local port 9093 is being forwarded successfully to an Alertmanager Pod.

      Visit http://localhost:9093 in your web browser. You should see the following Alertmanager Alerts page:

      Alertmanager Alerts Page

      From here, you can explore firing alerts and optionally silencing them. To learn more about Alertmanager, consult the official Alertmanager documentation.

      In the next step, you'll learn how to optionally configure and scale some of the monitoring stack components.

      Step 6 — Configuring the Monitoring Stack (optional)

      The manifests included in the DigitalOcean Kubernetes Cluster Monitoring Quickstart repository can be modified to use different container images, different numbers of Pod replicas, different ports, and customized configuration files.

      In this step, we'll provide a high-level overview of each manifest’s purpose, and then demonstrate how to scale Prometheus up to 3 replicas by modifying the master manifest file.

      To begin, navigate into the manifests subdirectory in the repo, and list the directory’s contents:


      alertmanager-0serviceaccount.yaml alertmanager-configmap.yaml alertmanager-operated-service.yaml alertmanager-service.yaml . . . node-exporter-ds.yaml prometheus-0serviceaccount.yaml prometheus-configmap.yaml prometheus-service.yaml prometheus-statefulset.yaml

      Here you'll find manifests for the different monitoring stack components. To learn more about specific parameters in the manifests, click into the links and consult the comments included throughout the YAML files:






      • prometheus-0serviceaccount.yaml: The Prometheus Service Account, ClusterRole and ClusterRoleBinding.
      • prometheus-configmap.yaml: A ConfigMap that contains three configuration files:

        • alerts.yaml: Contains a preconfigured set of alerts generated by kubernetes-mixin (which was also used to generate the Grafana dashboards). To learn more about configuring alerting rules, consult Alerting Rules from the Prometheus docs.
        • prometheus.yaml: Prometheus's main configuration file. Prometheus has been preconfigured to scrape all the components listed at the beginning of Step 2. Configuring Prometheus goes beyond the scope of this article, but to learn more, you can consult Configuration from the official Prometheus docs.
        • rules.yaml: A set of Prometheus recording rules that enable Prometheus to compute frequently needed or computationally expensive expressions, and save their results as a new set of time series. These are also generated by kubernetes-mixin, and configuring them goes beyond the scope of this article. To learn more, you can consult Recording Rules from the official Prometheus documentation.
      • prometheus-service.yaml: The Service that exposes the Prometheus StatefulSet.

      • prometheus-statefulset.yaml: The Prometheus StatefulSet, configured with 2 replicas. This parameter can be scaled depending on your needs.

      Example: Scaling Prometheus

      To demonstrate how to modify the monitoring stack, we'll scale the number of Prometheus replicas from 2 to 3.

      Open the sammy-cluster-monitoring_manifest.yaml master manifest file using your editor of choice:

      • nano sammy-cluster-monitoring_manifest.yaml

      Scroll down to the Prometheus StatefulSet section of the manifest:


      . . . apiVersion: apps/v1beta2 kind: StatefulSet metadata: name: sammy-cluster-monitoring-prometheus labels: &Labels k8s-app: prometheus sammy-cluster-monitoring prometheus spec: serviceName: "sammy-cluster-monitoring-prometheus" replicas: 2 podManagementPolicy: "Parallel" updateStrategy: type: "RollingUpdate" selector: matchLabels: *Labels template: metadata: labels: *Labels spec: . . .

      Change the number of replicas from 2 to 3:


      . . . apiVersion: apps/v1beta2 kind: StatefulSet metadata: name: sammy-cluster-monitoring-prometheus labels: &Labels k8s-app: prometheus sammy-cluster-monitoring prometheus spec: serviceName: "sammy-cluster-monitoring-prometheus" replicas: 3 podManagementPolicy: "Parallel" updateStrategy: type: "RollingUpdate" selector: matchLabels: *Labels template: metadata: labels: *Labels spec: . . .

      When you're done, save and close the file.

      Apply the changes using kubectl apply -f:

      • kubectl apply -f sammy-cluster-monitoring_manifest.yaml --namespace default

      You can track progress using kubectl get pods. Using this same technique, you can update many of the Kubernetes parameters and much of the configuration for this observability stack.


      In this tutorial, you installed a Prometheus, Grafana, and Alertmanager monitoring stack into your DigitalOcean Kubernetes cluster with a standard set of dashboards, Prometheus rules, and alerts.

      You may also choose to deploy this monitoring stack using the Helm Kubernetes package manager. To learn more, consult How to Set Up DigitalOcean Kubernetes Cluster Monitoring with Helm and Prometheus. One additional way to get this stack up and running is to use the DigitalOcean Marketplace Kubernetes Monitoring Stack solution, currently in beta.

      The DigitalOcean Kubernetes Cluster Monitoring Quickstart repository is heavily based on and modified from Google Cloud Platform’s click-to-deploy Prometheus solution. A full manifest of modifications and changes from the original repository can be found in the Quickstart repo’s changes.txt file.

      Source link