Shulou(Shulou.com)06/01 Report--

This article introduces you how to use Django and Prometheus as well as Kubernetes to customize application indicators, the content is very detailed, interested friends can refer to, hope to be helpful to you.

This paper emphasizes the importance of customizing metrics for applications, and demonstrates how to design metrics and integrate Prometheus into Django projects with code examples, which provides a reference for developers who use Django to build applications.

Why is it important to customize metrics?

Although there is a great deal of discussion on this topic, the importance of custom metrics for applications cannot be overemphasized. Unlike the core service metrics collected for Django applications (application and web server statistics, key database and cache operation metrics), custom metrics are business-specific data points whose boundaries and thresholds are known only to you, which is actually very interesting.

What kind of indicators are useful? Consider the following points:

Run an e-commerce site and track the average number of orders. All of a sudden, the number of orders is not so even. With reliable application metrics and monitoring, you can capture Bug before the loss is exhausted.

You are writing a crawler that grabs the latest articles from a news website every hour. All of a sudden, the latest article is not new. Reliable indicators and monitoring can reveal the problem earlier.

I think you've understood the point.

Set up the Django application

In addition to the obvious pip install Django, we also need to add some additional packages for the pet project (demo). Continue and install pip install django-prometheus-client. This will give us a Prometheus client for Python, as well as some useful Django hook, including middleware and an elegant DB wrapper. Next, we will run the Django management command to start the project, update our settings to use the Prometheus client, and add Prometheus's URL to the URL configuration.

Start a new project and application

For this article, and in line with the agency's brand, we have set up a dog walking service. Note that it doesn't actually do anything, but it's enough to serve as a teaching example. Execute the following command:

Django-admin.py startproject demopython manage.py startapp walker#settings.pyINSTALLED_APPS = [... 'walker',.]

Now, let's add some basic models and views. For simplicity, I only implement what I'm going to validate. If you want a complete example, you can get the source code from this demo application.

# walker/models.pyfrom django.db import modelsfrom django_prometheus.models import ExportModelOperationsMixinclass Walker (ExportModelOperationsMixin ('walker'), models.Model): name = models.CharField (max_length=127) email = models.CharField (max_length=127) def _ str__ (self): return f' {self.name} / / {self.email} ({self.id})' class Dog (ExportModelOperationsMixin ('dog') Models.Model): SIZE_XS = 'xs' SIZE_SM =' sm' SIZE_MD = 'md' SIZE_LG =' lg' SIZE_XL = 'xl' DOG_SIZES = ((SIZE_XS,' xsmall'), (SIZE_SM, 'small'), (SIZE_MD,' medium'), (SIZE_LG, 'large'), (SIZE_XL,' xlarge') ) size = models.CharField (max_length=31, choices=DOG_SIZES, default=SIZE_MD) name= models.CharField (max_length=127) age = models.IntegerField () def _ str__ (self): return f'{self.name} / / {self.age} y ({self.size}) 'class Walk (ExportModelOperationsMixin (' walk'), models.Model): dog = models.ForeignKey (Dog, related_name='walks') On_delete=models.CASCADE) walker = models.ForeignKey (Walker, related_name='walks', on_delete=models.CASCADE) distance = models.IntegerField (default=0, help_text='walk distance (in meters)') start_time = models.DateTimeField (null=True, blank=True, default=None) end_time = models.DateTimeField (null=True, blank=True) Default=None) @ property def is_complete (self): return self.end_time is not None @ classmethod def in_progress (cls): "get the list of `Walk`s currently in progress" return cls.objects.filter (start_time__isnull=False) End_time__isnull=True) def _ _ str__ (self): return f'{self.walker.name} / / {self.dog.name} @ {self.start_time} ({self.id})'# walker/views.pyfrom django.shortcuts import render, redirectfrom django.views import Viewfrom django.core.exceptions import ObjectDoesNotExistfrom django.http import HttpResponseNotFound, JsonResponse, HttpResponseBadRequest, Http404from django.urls import reversefrom django.utils.timezone import nowfrom walker import models, formsclass WalkDetailsView (View): def get_walk (self) Walk_id=None): try: return models.Walk.objects.get (id=walk_id) except ObjectDoesNotExist: raise Http404 (f'no walk with ID {walk_id} in progress') class CheckWalkStatusView (WalkDetailsView): def get (self, request, walk_id=None * * kwargs): walk = self.get_walk (walk_id=walk_id) return JsonResponse ({'complete': walk.is_complete}) class CompleteWalkView (WalkDetailsView): def get (self, request, walk_id=None, * * kwargs): walk = self.get_walk (walk_id=walk_id) return render (request,' index.html', context= {'form': forms.CompleteWalkForm (instance=walk)}) def post (self, request, walk_id=None * * kwargs): try: walk = models.Walk.objects.get (id=walk_id) except ObjectDoesNotExist: return HttpResponseNotFound (content=f'no walk with ID {walk_id} found') if walk.is_complete: return HttpResponseBadRequest (content=f'walk {walk.id} is already complete') form = forms.CompleteWalkForm (data=request.POST Instance=walk) if form.is_valid (): updated_walk = form.save (commit=False) updated_walk.end_time = now () updated_walk.save () return redirect (f'{reverse ("walk_start")}? walk= {walk.id}') return HttpResponseBadRequest (content=f'form validation failed with errors {form.errors}') class StartWalkView (View): def get (self) Request): return render (request, 'index.html', context= {' form': forms.StartWalkForm ()}) def post (self Request): form = forms.StartWalkForm (data=request.POST) if form.is_valid (): walk= form.save (commit=False) walk.start_time = now () walk.save () return redirect (f'{reverse ("walk_start")}? walk= {walk.id}') return HttpResponseBadRequest (content=f'form validation failed with errors {form.errors}')

Update application settings and add Prometheus urls

Now that we have a Django project and the corresponding settings, we can add the required configuration items for django-prometheus. Add the following configuration to settings.py:

INSTALLED_APPS = [... 'django_prometheus',.] MIDDLEWARE = [' django_prometheus.middleware.PrometheusBeforeMiddleware',. 'django_prometheus.middleware.PrometheusAfterMiddleware',] # we're assuming a Postgres DB here because, well, that's just the right choice:) DATABASES = {' default': {'ENGINE':' django_prometheus.db.backends.postgresql', 'NAME': os.getenv (' DB_NAME'), 'USER': os.getenv (' DB_USER'), 'PASSWORD': os.getenv (' DB_PASSWORD') 'HOST': os.getenv ('DB_HOST'),' PORT': os.getenv ('DB_PORT',' 5432'),},}

Add url configuration to urls.py:

Urlpatterns = [... Path (', include ('django_prometheus.urls')),]

Now we have a configured basic application and are ready for integration.

Add Prometheus metrics

Because django-prometheus provides out-of-the-box functionality, we can immediately track some basic model operations, such as inserts and deletes. You can see these at / metricsendpoint:

Default metrics provided by django-prometheus

Let's make it more interesting.

Add a walker/metrics.py file to define some basic metrics to track.

# walker/metrics.pyfrom prometheus_client import Counter, Histogramwalks_started = Counter ('walks_started',' number of walks started') walks_completed = Counter ('walks_completed',' number of walks completed') invalid_walks = Counter ('invalid_walks',' number of walks attempted to be started, but invalid') walk_distance = Histogram ('walk_distance',' distribution of distance walked', buckets= [0,50,200,400,800, 1600, 3200])

It's simple, isn't it? The Prometheus documentation well explains the purpose of each metric type. In short, we use counters to represent metrics that grow strictly over time, and histograms to track metrics that contain value distribution. Let's start validating the code for the application.

# walker/views.py...from walker import metrics...class CompleteWalkView (WalkDetailsView):... Def post (self, request, walk_id=None, * * kwargs): If form.is_valid (): updated_walk = form.save (commit=False) updated_walk.end_time = now () updated_walk.save () metrics.walks_completed.inc () metrics.walk_distance.observe (updated_walk.distance) return redirect (f'{reverse ("walk_start")}? walk= {walk.id}') Return HttpResponseBadRequest (content=f'form validation failed with errors {form.errors}')... class StartWalkView (View):... Def post (self Request): if form.is_valid (): walk= form.save (commit=False) walk.start_time = now () walk.save () metrics.walks_started.inc () return redirect (f'{reverse ("walk_start")}? walk= {walk.id}') metrics.invalid_walks.inc () return HttpResponseBadRequest (content=f'form validation failed with errors {form.errors}')

Send several sample requests and you can see that the new metrics have been generated.

Show walking distance and create indicators for walking

The defined metrics can now be found in prometheus.

So far, we have added custom metrics to the code, integrated applications to track metrics, and verified that these metrics have been updated and available on / metrics. Let's continue to deploy instrumented applications to the Kubernetes cluster.

Deploy applications using Helm

I will only list the configuration related to tracking and exporting metrics, and the complete Helm chart deployment and service configuration can be found in the demo application. As a starting point, there are some deployment and configmap configurations related to exported metrics:

# helm/demo/templates/nginx-conf-configmap.yamlapiVersion: v1kind: ConfigMapmetadata: name: {{include "demo.fullname". }-nginx-conf... data: demo.conf: | upstream app_server {server 127.0.0.1 demo.conf 8000 fail_timeout=0;} server {listen 80; client_max_body_size 4G; # set the correct host (s) for your site server_name {{range .Values.ingress.hosts}} {{. } {{- end}}; keepalive_timeout 5; root / code/static; location / {# checks for static file, if not found proxy to app try_files $uri @ proxy_to_app;} location ^ ~ / metrics {auth_basic "Metrics"; auth_basic_user_file / etc/nginx/secrets/.htpasswd; proxy_pass http://app_server; } location @ proxy_to_app {proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Host $http_host; # we don't want nginx trying to do something clever with # redirects, we set the Host: header above already. Proxy_redirect off; proxy_pass http://app_server;}} # helm/demo/templates/deployment.yamlapiVersion: apps/v1kind: Deployment... Spec: metadata: labels: app.kubernetes.io/name: {{include "demo.name". }} app.kubernetes.io/instance: {{.Release.Name}} app: {{include "demo.name". }} volumes:...-name: nginx-conf configMap: name: {{include "demo.fullname". }-nginx-conf-name: prometheus-auth secret: secretName: prometheus-basic-auth. Containers:-name: {{.Chart.Name}}-nginx image: "{{.Values.nginx.image.repository}: {{.Values.nginx.image.tag}}" imagePullPolicy: IfNotPresent volumeMounts:...-name: nginx-conf mountPath: / etc/nginx/conf.d/-name: prometheus -auth mountPath: / etc/nginx/secrets/.htpasswd ports:-name: 80 protocol: TCP-name: {{.Chart.Name}} image: "{{.Values.image.repository}: {{.Values.image.tag}}" imagePullPolicy: {{.Values.image. PullPolicy}} command: ["gunicorn" "--worker-class", "gthread", "--threads", "3", "--bind", "0.0.0.0 demo.wsgi:application" 8000 "," demo.wsgi:application "] env: {{include" demo.env ". | | nindent 12}} ports:-name: gunicorn containerPort: 8000 protocol: TCP...

It's nothing magical, just some YAML. There are two key points that need to be emphasized:

We put / metrics after validation through a nginx reverse proxy and set the auth_basic instruction set for the location block. You may want to deploy gunicorn after a reverse proxy, but doing so gives you the added benefit of protecting metrics.

We use multithreaded gunicorn instead of multiple worker. Although multiprocess mode can be enabled for Prometheus clients, installation can be more complex in a Kubernetes environment. Why is this important? The risk of running multiple worker in a pod is that each worker will report its own set of metric values at collection time. However, because the service is set to the pod level in the Prometheus Kubernetes SD scrape configuration, these (potential) jump values are incorrectly classified as counter resets, resulting in inconsistent measurements. You don't necessarily need to follow all the steps above, but the point is: if you don't know much, you should start with a single-threaded + single-worker gunicorn environment, or a single-worker+ multithreaded environment.

Deploy Prometheus using Helm

Based on the Helm help documentation, deploying Prometheus is very simple and requires no extra work:

Helm upgrade-install prometheus stable/prometheus

In a few minutes, you should be able to access Prometheus's pod via port-forward (the default container port is 9090).

Configure Prometheus scrape targets for the application

Prometheus Helm chart has a lot of customization options, but we only need to set up extraScrapeConfigs. Create a values.yaml file. You can skip this section and use the demo app as a reference. The contents of the document are as follows:

ExtraScrapeConfigs:-job_name: demo scrape_interval: 5s metrics_path: / metrics basic_auth: username: prometheus password: prometheus tls_config: insecure_skip_verify: true kubernetes_sd_configs:-role: endpoints namespaces: names:-default relabel_configs:-source_labels: [_ _ meta_kubernetes_service_label_app] Regex: demo action: keep-source_labels: [_ meta_kubernetes_endpoint_port_name] regex: http action: keep-source_labels: [_ meta_kubernetes_namespace] target_label: namespace-source_labels: [_ meta_kubernetes_pod_name] target_label: pod-source_labels: [_ meta_kubernetes_service_name] Target_label: service-source_labels: [_ meta_kubernetes_service_name] target_label: job-target_label: endpoint replacement: http

Once created, you can update the configuration for prometheus deployment by doing the following.

Helm upgrade-- install prometheus-f values.yaml

To verify that all the steps are configured correctly, open the browser and type http://localhost:9090/targets (assuming you have already entered the Pod running prometheus through port-forward). If you see the demo app in the target list, it's working properly.

On how to use Django and Prometheus and Kubernetes customized application indicators to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.