k8s мониторинг (4) мониторинг хоста

Kubernetes

Эта статья является частью серии мониторов k8s, остальная часть статьи:

  1. мониторинг k8s (1) Установить Prometheus
  2. Мониторинг k8s (2) Мониторинг компонентов и модулей кластера
  3. мониторинг k8s (3) prometheus-adapter

Четвертая статья мониторинга k8s, эта статья о мониторинге показателей хоста. Официально и большинство пользователей будут использовать node_exporter для этой работы, но я предпочитаюtelegraf. Причина в том, что node_exporter имеет следующие основные болевые точки:

  • Индикаторов слишком много.Только для cpu у каждого ядра cpu 6 индикаторов.Если ядер 72, то индикаторов только для cpu 432, что сложно понять;
  • Нет возможности настроить собираемые метрики, вы либо собираете такие метрики, либо не собираете их, вы не можете просто собирать какие-то части этих метрик;
  • Не поддерживает пользовательские сценарии мониторинга;
  • Индикаторов 11 состояний tcp нет (может я не знаю как это посмотреть?), а что делать с таким количеством сетевых индикаторов я не знаю и ни в одном не могу разобраться.

А у телеграфа этой проблемы нет. Ввиду этого в этой статье будут развернуты оба варианта, выбор за вами.

Как обычно, все файлы yml загружаются вgithub.

node_exporter

Просто обратите внимание на следующие моменты:

  • Используйте daemonset, чтобы убедиться, что каждый узел k8s развернут;
  • Чтобы смонтировать как /proc, так и /sys хоста, кажется, что корень также смонтирован;
  • Используйте пространство имен хост-сети.

Всего 5 файлов развертывания, все начинаются сnode-exporter-В начале конкретная функция очевидна с первого взгляда, поэтому я не буду много говорить. Первыйkubectl apply, подождав, пока модуль запустится нормально, вы можете напрямую получить доступ к порту 9100 хоста, чтобы увидеть, какие там индикаторы:

curl 127.0.0.1:9100/metrics

Убедившись, что метрики собраны на месте, измените prometheus-config.yml и добавьте следующую конфигурацию:

- job_name: node_exporter
  kubernetes_sd_configs:
  - role: endpoints
    namespaces:
      names:
      - monitoring
  scrape_interval: 30s
  scrape_timeout: 30s
  tls_config:
    insecure_skip_verify: true
  bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
  relabel_configs:
  - action: keep
    source_labels:
    - __meta_kubernetes_service_label_k8s_app
    regex: node-exporter

Обратите внимание, что имя тега службы будетk8s-appсередина-Здесь_, иначе reload prometheus сообщит об ошибке.

Выполнить после модификацииkubectl apply -f prometheus-config.yml, на этом этапе вам лучше войти в контейнер prometheus, чтобы проверить, действует ли файл конфигурации.Убедившись, что он действует, вы можете перезагрузить его на хосте:

curl -XPOST POD_IP:9090/-/reload

Затем вы можете увидеть это в цели веб-страницы prometheus.

telegraf

В node_exporter слишком много неизвестных индикаторов, которые будут занимать много дополнительных ресурсов, поэтому я выбираю телеграф с большей настройкой. Telegraf — это инструмент для сбора индикаторов, разработанный InfluxData с использованием go.Другой продукт InfluxData, influxdb, очень известен.Они вместе с оставшимися Chronograf и Kapacitor составляют тик системы мониторинга InfluxData.

Я не буду упоминать здесь галочку, мы будем использовать только телеграф. telegraf чем-то похож на logstash и разделен на четыре части: ввод, процессор, агрегатор и вывод, и каждая часть снабжена определенными функциями с помощью различных подключаемых модулей. Можно понять, что все функции телеграфа обеспечиваются плагинами, но плагины делятся на четыре категории.

Здесь будут использоваться вход, выход и процессор, как и для агрегатора в (полимеризация, используется для расчета максимума, минимума, среднего значения во времени и т. д.), которые могут быть интересны для изучения обуви.

Здесь мы используем телеграф для сбора показателей производительности хоста.Поскольку существует много типов показателей, включая процессор, память, диск, сеть и т. д., будут использоваться несколько входных плагинов. Некоторые плагины предоставляют некоторые параметры, которые позволяют нам лучше контролировать метрики, которые нам нужно собрать, что очень удобно и намного полезнее, чем сбор всех сразу с помощью node_exporter.

После получения этих метрик, т.к. их нужно собирать через prometheus, будет использоваться prometheus Output, то есть все собранные метрики будут отображаться на странице metricc.

Прежде всего, поговорим о его конфигурационном файле, все его конфигурации находятся в этом конфигурационном файле. Прежде чем разбираться в конфигурационном файле, нам нужно знать, что у самого телеграфа есть некоторые понятия:

  • поле: название индикатора;
  • tag: тег в индикаторе.

Во избежание повторного отображения, я сразу вставлю содержимое configmap, нам нужно только начать с[agent]Просто начните искать.

apiVersion: v1
kind: ConfigMap
metadata:
  name: telegraf
  namespace: monitoring
  labels:
    name: telegraf
data:
  telegraf.conf: |+
    [agent]
      interval = "10s"
      round_interval = true
      collection_jitter = "1s"
      omit_hostname = true
    [[outputs.prometheus_client]]
      listen = ":9273"
      collectors_exclude = ["gocollector", "process"]
      metric_version = 2
    [[inputs.cpu]]
      percpu = false
      totalcpu = true
      collect_cpu_time = false
      report_active = false
    [[inputs.disk]]
      ignore_fs = ["tmpfs", "devtmpfs", "devfs", "iso9660", "overlay", "aufs", "squashfs"]
      [inputs.disk.tagdrop]
        path = ["/etc/telegraf", "/dev/termination-log", "/etc/hostname", "/etc/hosts", "/etc/resolv.conf"]
    [[inputs.diskio]]
    [[inputs.kernel]]
    [[inputs.mem]]
      fielddrop = ["slab", "wired", "commit_limit", "committed_as", "dirty", "high_free", "high_total", "huge_page_size", "huge_pages_free", "low_free", "low_total", "mapped", "page_tables", "sreclaimable", "sunreclaim", "swap_cached", "swap_free", "vmalloc_chunk", "vmalloc_total", "vmalloc_used", "write_back", "write_back_tmp"]
    [[inputs.processes]]
    [[inputs.system]]
    [[inputs.netstat]]
    [[inputs.net]]
      ignore_protocol_stats = true
      interfaces = ["eth*", "bond*", "em*"]
      fielddrop = ["packets_sent", "packets_recv"]

конфигурационный файл

Официальная документация для файлов конфигурации телеграфаздесь, контента не много, можно глянуть. Неважно, если вы не хотите это видеть, я объясню все конфигурации, которые у меня есть здесь. телеграф использует формат файла конфигурации toml,[]представляет собой словарь,[[]]Представляет список. Преобразование в yml выглядит так:

agent:
  # 采集间隔
  interval: 30s
  # 没有这个貌似就只会采集一次
  round_interval: true
  # 多个 input 如果在同一时间进行采集，可能会造成 cpu 尖刺，使用这个时间错开
  collection_jitter: 1s
  # 不会为所有的指标添加 hostname tag（标签）
  omit_hostname: true
inputs:
  - disk:
    # 不收集指定的文件系统
    ignore_fs: []
    # 只要标签中有 path 为以下值的，不收集对应的指标
    tagdrop:
      path: ["/etc/telegraf", "/dev/termination-log", "/etc/hostname", "/etc/hosts", "/etc/resolv.conf"]
  - system: {}
  - cpu:
    # 不为每颗 cpu 都单独创建指标，node_exporter 就使用这种方式，你还无法关掉，但是 telegraf 可以
    percpu: false
    # 这是绝对要开启的，统计总的 cpu 使用
    totalcpu: true
    # 统计 cpu 时间，看你需要，一般不开启
    collect_cpu_time: false
    # 是否新增一个 active 的指标，它的值是除了 idle 之外的值相加的结果，如果不统计 cpu 时间的话，可以直接用 100 减去
    # idle，得到的值就是 active 的值
    report_active: false
  - mem:
    # 字段名中包含这些的都不收集，至于字段有哪些，那就要看 mem inputs 的文档了
    # 由于老夫学艺不精，很多内存指标都看不懂，干脆都干掉了，你们自行掂量
    fielddrop: []
outputs:
  - prometheus_client:
    listen: :9273
    # 排除 go 本身（goroutine、gc 等）和 process 这两种指标
    collectors_exclude: ["gocollector", "process"]

Среди четырех основных частей телеграфа только Процессор не имеет соответствующего ключевого слова.В настоящее время он имеет только функцию фильтрации, которая используется во Вводе, Выводе и Агрегаторе. Fielddrop и tagdrop в приведенном выше файле конфигурации Input принадлежат процессору и используются для фильтрации индикаторов. Отфильтрованные ключевые слова:

  • namepass: В качестве условия фильтрации используется имя индикатора. Pass — это белый список. Собираются только те ключевые слова, которые содержатся в имени. Его значение — список, и элементы в списке могут использовать подстановочные знаки;
  • namedrop:черный список. Следует отметить, что имя и поле не одно и то же, например, в индикаторе памяти есть поле total, но оно называется mem_total;
  • fieldpass: фильтр по имени поля, его тип значения также список;
  • fielddrop:черный список;
  • tagpass: если тег содержит определенный ключ/значение, метрика не будет собираться. Обратите внимание, что его тип значения — словарь, подробности см. выше;
  • tagdrop:черный список;
  • taginclude: Это для удаления тега, тип значения — список. Теги в списке зарезервированы;
  • tagexclude: Все теги в списке удалены.

я только что использовалtagdropа такжеfielddrop, вы можете использовать его, если вам это нужно. Через Процессор мы легко можем удалить ненужные нам индикаторы, что очень удобно.

Сочетание их, вы должны легко понять конфигурацию, которую я использую здесь. Здесь я собрал только некоторые общие индикаторы системы, если у вас есть другие потребности, вы можете проверить официальныйвходная документация, множество плагинов на ваш выбор.

pod

Очевидно, что Telegraf также использует daemonset, и необходимо упомянуть некоторые ключевые моменты его конфигурации модуля.

  • Нужно монтировать рут в контейнер, монтировать /proc и /sys отдельно, у индикатора диска будут проблемы;
  • Пусть телеграф собирает директорию смонтированного хоста через переменные окружения HOST_PROC, HOST_SYS и HOST_MOUNT_PREFIX;
  • И hostNetwork, и hostPID должны быть истинными;
  • Используйте securityContext, чтобы разрешить запуск модуля от имени пользователя без полномочий root. Указанный uid — это uid пользователя на хосте. Неважно, существует ли пользователь в образе или нет. После запуска модуля вы можете получить доступ кps -ef|grep telegrafПросмотр запущенных пользователей.
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: telegraf
  namespace: monitoring
  labels:
    k8s-app: telegraf
spec:
  selector:
    matchLabels:
      name: telegraf
  template:
    metadata:
      labels:
        name: telegraf
    spec:
      containers:
      - name: telegraf
        image: telegraf:1.13.2-alpine
        resources:
          limits:
            memory: 500Mi
          requests:
            cpu: 500m
            memory: 500Mi
        env:
        - name: "HOST_PROC"
          value: "/host/proc"
        - name: "HOST_SYS"
          value: "/host/sys"
        - name: "HOST_MOUNT_PREFIX"
          value: "/host"
        volumeMounts:
        - name: config
          mountPath: /etc/telegraf
          readOnly: true
        - mountPath: /host
          name: root
          readOnly: true
      hostNetwork: true
      hostPID: true
      nodeSelector:
        kubernetes.io/os: linux
      securityContext:
        runAsNonRoot: true
        runAsUser: 65534
      tolerations:
      - operator: Exists
      terminationGracePeriodSeconds: 30
      volumes:
      - name: config
        configMap:
          name: telegraf
      - hostPath:
          path: /
        name: root

Я не буду много говорить о сервисе, который использует prometheus для его обнаружения. После применения этих трех файлов измените конфигурацию prometheus.

Изменить конфигурацию прометея

В зависимости от использования конфигурация prometheus может отличаться, сначала настройте:

    - job_name: telegraf
      kubernetes_sd_configs:
      - role: endpoints
        namespaces:
          names:
          - monitoring
      scrape_interval: 30s
      scrape_timeout: 30s
      tls_config:
        insecure_skip_verify: true
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      relabel_configs:
      - action: keep
        source_labels:
        - __meta_kubernetes_service_label_k8s_app
        regex: telegraf
      - source_labels:
        - __meta_kubernetes_endpoint_node_name
        target_label: instance

Здесь добавлена ​​только одна конфигурация, которая заключается в замене метки экземпляра именем узла вместо значения по умолчанию.__address__. Если вы хотите сохранить экземпляр по умолчанию, вы можете заменить экземпляр на желаемое имя. Я думаю, что индикаторов слишком много, поэтому я заменил экземпляр по умолчанию именем узла.

Причина, по которой используется имя узла, заключается в том, что оно используется вместеkubectl top nodeКоманды (имеется в виду предыдущая статья этой серии). Поэтому значение тега экземпляра такое же, как вы используетеkubectl get nodeПоявляющиеся значения находятся во взаимно однозначном соответствии (в основном одинаковые). Конечно, если вы можете напрямую использовать команду kubectl top node, то нет необходимости добавлять эту метку.

После модификации применить, а потом еще и выполнить в контейнер prometheus, поставить галочку/etc/prometheus/config/prometheus.ymlизменилось. Дождавшись изменения, вернитесь на хост и выполните его;

curl -XPOST PROMETHEUS_CONTAINER_IP:9090/-/reload

После перезагрузки вы можете напрямую получить доступ к странице индикатора через IP-адрес хоста.

curl IP:9273/metrics

Видно, что индикаторы ясны и легко понять, а число очень мало, что намного сильнее, чем node_exporter.

Изменить конфигурацию адаптера prometheus

существуетпредыдущий постВ , мы разворачиваем адаптер prometheus и используем его для предоставления API ресурсной метрики, то есть через него мы можем использовать команду kubectl top. Но так как я удалил существованиеid="/"Индекс метки, поэтому оператор запроса индекса узла по умолчанию недействителен.

Если вы хотите использовать его, вы можете восстановить ранее удаленные индикаторы.Условие запроса по умолчанию выглядит следующим образом:

# cpu
sum(rate(container_cpu_usage_seconds_total{<<.LabelMatchers>>, id='/'}[1m])) by (<<.GroupBy>>)

# memory
sum(container_memory_working_set_bytes{<<.LabelMatchers>>,id='/'}) by (<<.GroupBy>>)

Но если восстановить их все, то количество показателей сильно возрастет, и часть выигрышей перевесит выигрыши. Теперь, когда мы собрали метрики хоста, мы можем полностью запросить метрики хоста, и вообще нет необходимости запрашивать контейнер. Поэтому нам просто нужно заменить эти два оператора запроса следующими двумя:

# cpu
100-cpu_usage_idle{cpu="cpu-total", <<.LabelMatchers>>}

# mem
mem_used{<<.LabelMatchers>>}

Но вы должны убедиться, что следующая конфигурация должна существовать:

        resources:
          overrides:
            instance:
              resource: nodes

Эта конфигурация сопоставляет ресурсы узла со значением тега экземпляра. Когда вы выполняете kubectl top node, он сначала получает все узлы, а затем вводит каждый узел в выражение запроса, например, для запроса процессора, имя узла которого — k8s-node1:

100-cpu_usage_idle{cpu="cpu-total", instance="k8s-node1"}

Полную конфигурацию можно найти наgithubКак вы можете видеть выше, на самом деле изменены всего два оператора запроса.

После применения вам нужно удалить модуль адаптера prometheus, чтобы перезапустить его, а затем вы можете выполнить команду kubectl top node, но отображение процессора не точное, может быть, отсутствует cpu_usage_total? Я не очень хорошо знаю логику реализации адаптера.Заинтересованная детская обувь может изучить? Но память точна, мы просто смотрим на память.

Категории