Mesosbeat: Elastic Beats Based on Metricbeat

What is the Mesosbeat

Mesosbeat is a beat based on Metricbeat which read metrics from Apache Mesos HTTP API and indexes them into Elasticsearch or Logstash.

What is the Apache Mesos?

Apache Mesos is a cluster manager that provides efficient resource isolation and sharing across distributed applications or frameworks.

Run Mesosbeat

First, setup Golang environment (if you don't have it already)
To create a binary run the make command. This will create the binary in your beats directory.

cd $GOPATH
mkdir -p src/github.com/berfinsari
cd src/github.com/berfinsari
git clone https://github.com/berfinsari/mesosbeat.git
cd mesosbeat
make

To run mesosbeat, execute the binary. This will automatically load the default configuration which was generated by make update.

./mesosbeat -e -d "*"

This will run the beat with debug output enabled to the console to directly see what is happening. Stop the beat with CTRL-C.

If you can not see the Mesos module output, you need to enable the Mesos module:

./mesosbeat modules enable mesos

Now Mesos module is enabled and ready to collects metrics.

Configuration

Mesosbeat has some settings. If you want to change some config options adjust the modules.d/mesos.yml file to your needs.

Here is a sample configuration:

- module: mesos
  metricsets: ["master"]
  period: 10s
  hosts: ["localhost:5050"]

module: The name of the module to run.
metricsets: A list of metricsets to execute.(For now, mesos module have one metricset)
period: How often the metricsets are executed. If a system is not reachable, Metricbeat returns an error for each period.
hosts: A list of hosts of fetch information from.

Mesos Stats

Mesosbeat collects metrics for Mesos master and returns all available metrics from the /metrics/snapshot API endpoint on Mesos master. Master metricset provides information regarding the current metrics tracked by the system.

Metrics Collected

Resources
These metrics provide information about the total resources available in the cluster and their current usage.

    "master": {
      "gpus_used": 0,
      "gpus_revocable_total": 0,
      "mem_percent": 0,
      "disk_revocable_percent": 0,
      "invalid_status_update_acknowledgements": 0,
      "event_queue_dispatches": 8,
      "gpus_revocable_used": 0,
      "mem_total": 14886,
      "disk_revocable_used": 0,
      "cpus_revocable_total": 0,
      "cpus_revocable_used": 0,
      "disk_percent": 0,
      "cpus_used": 0,
      "gpus_revocable_percent": 0,
      "cpus_total": 12,
      "disk_total": 172196,
      "cpus_revocable_percent": 0,
      "cpus_percent": 0,
      "mem_used": 0,
      "disk_revocable_total": 0,
      "gpus_total": 0,
      "mem_revocable_total": 0,
      "disk_used": 0,
      "gpus_percent": 0,
      "mem_revocable_percent": 0,
      "mem_revocable_used": 0,
      },


Master
These metrics provide information about whether a master is currently elected and how long it has been running.

    "master": {
      "elected": 1,
      "uptime_secs": 2113.715932928,

      },

System
These metrics provide information about the resources available on this master node and their current usage.

    "system": {
      "cpus_total": 12,
      "load_15min": 0.37,
      "load_5min": 0.52,
      "load_1min": 0.63,
      "mem_free_bytes": 9097818112,
      "mem_total_bytes": 16683503616
    },


Agents
These metrics provide information about agent events, agent counts, and agent states.

   "master": {
     "slave_registrations": 0,

      "slave_unreachable_scheduled": 0,
      "slaves_inactive": 0,
      "slave_unreachable_completed": 0,
      "slaves_unreachable": 0,
      "slaves_connected": 1,

      "slave_removals": 0,

      "slaves_active": 1,

      "slaves_disconnected": 0,

      "slave_unreachable_canceled": 0,
      "slave_reregistrations": 1,

    },

Frameworks
These metrics provide information about the registered frameworks in the cluster.

  "master": {
      "frameworks_active": 0,

      "frameworks_connected": 0,

      "frameworks_disconnected": 0,
      "frameworks_inactive": 0,
      "outstanding_offers": 0,
   },

Tasks
These metrics provide information about active and terminated tasks.

  "master": {
      "tasks_error": 0,

      "tasks_lost": 0,
      "tasks_running": 0,
      "tasks_killed": 0,
      "tasks_killing": 0,

      "tasks_failed": 0,

      "tasks_finished": 0,

      "tasks_starting": 0,

      "tasks_unreachable": 0,

      "tasks_staging": 0,
   },

Messages
These metrics provide information about messages between the master and the agents and between the framework and the executors.

  "master": {
      "invalid_executor_to_framework_messages": 0,

      "invalid_framework_to_executor_messages": 0,

      "invalid_operation_status_update_acknowledgements": 0,

      "invalid_status_updates": 0,

      "dropped_messages": 0,

      "messages_authenticate": 0,

      "messages_deactivate_framework": 0,

      "messages_decline_offers": 0,

      "messages_executor_to_framework": 0,

      "messages_exited_executor": 0,

      "messages_framework_to_executor": 0,

      "messages_kill_task": 0,

      "messages_launch_tasks": 0,

      "messages_operation_status_update_acknowledgement": 0,

      "messages_reconcile_operations": 0,

      "messages_reconcile_tasks": 0,

      "messages_register_framework": 0,

      "messages_register_slave": 0,

      "messages_reregister_framework": 0,

      "messages_reregister_slave": 1,

      "messages_resource_request": 0,

      "messages_revive_offers": 0,

      "messages_status_update": 0,

      "messages_status_update_acknowledgement": 0,

      "messages_unregister_framework": 0,
      "messages_unregister_slave": 0,

      "messages_update_slave": 1,

      "recovery_slave_removals": 0,
      "slave_Removals": {
        "reason_registered": 0,
        "reason_unhealthy": 0,
        "reason_unregistered": 0
      },
      "valid_framework_to_executor_messages": 0,
      "valid_operation_status_update_acknowledgements": 0

      "valid_status_update_acknowledgements": 0,

      "valid_status_updates": 0,

      "valid_executor_to_framework_messages": 0,

   },

Event queue
These metrics provide information about different types of events in the event queue.

  "master": {
      "event_queue_dispatches": 6,

      "event_queue_http_requests": 0,

      "event_queue_messages": 0,
      "operator_event_stream_subscribers": 0,

   },

Registrar
These metrics provide information about read and write latency to the agent registrar and replicate log metrics provide information about the replicated log underneath the registrar, which is the persistent store for masters.

    "registrar": {
      "log": {
        "ensemble_size": 1,
        "recovered": 1
      },
      "state_fetch_ms": 28.32896,
      "state_store_ms": 18.193152,
      "state_store_MS": {}
    }


Allocator
These metrics provide information about performance and resource allocations in the allocator.

    "allocator": {
      "mesos": {
        "allocation_run_latency_ms": 0.166912,
        "allocation_run_latency_MS": {
          "p50": 0.153088,
          "p90": 0.165888,
          "p999": 0.34411084799999886,
          "p95": 0.175872,
          "min": 0.036096,
          "max": 0.390912,
          "count": 1000,
          "p99": 0.19791872,
          "p9999": 0.3862318848000031
        },
        "resources": {
          "disk": {
            "offered_or_allocated": 0,
            "total": 172196
          },
          "mem": {
            "total": 14886,
            "offered_or_allocated": 0
          },
          "cpus": {
            "offered_or_allocated": 0,
            "total": 12
          }
        },
        "allocation_run_ms": 0.231936,
        "allocation_run_MS": {
          "max": 0.323072,
          "p50": 0.228096,
          "p90": 0.2439936,
          "count": 1000,
          "p95": 0.26039039999999997,
          "p999": 0.3100290559999997,
          "min": 0.070144,
          "p9999": 0.3217677056000009,
          "p99": 0.28597248
        },
        "allocation_runs": 2110
      }


You can check Mesos documentation for more information about Mesos metrics.

Envoyproxybeat: Elastic Beats for Envoy Proxy

What is the Envoyproxybeat

Envoyproxybeat is an Elastic Beat that reads stats from the Envoy Proxy and indexes them into Elasticsearch or Logstash.

Configuration Options

You need to adjust the envoyproxybeat.yml configuration file to your needs. Here is a sample configuration:

input:
  # Defines how often an event is sent to the output
  period: 30

  # Defines the http port serviced
  # Default to :9901
  port: :9901

  # Defines the http host serviced
  # Default to localhost
  host: localhost

Options

period

How often events are sent to the Elasticsearch.

period: 30

port and host

envoyproxybeat collect data from the Envoy Proxy the predefined to localhost: 5984. You should be careful when you change these settings.

port: :9901

host: localhost

Run Envoyproxybeat

First, setup Golang environment (if you don't have it already)

cd $GOPATH

mkdir -p src/github.com/berfinsari

cd src/github.com/berfinsari

git clone https://github.com/berfinsari/envoyproxybeat.git

cd envoyproxybeat

make

To run Envoyproxybeat with debugging output enabled, run:

./envoyproxybeat -c envoyproxybeat.yml -e -d "*"

Envoy Proxy Statistics

Envoy outputs numerous statistics which depend on how the server is configured. They can be seen locally via the /stats admin endpoint. The admin endpoint looks directly into the store to load all of the counters and gauges and print them.

Envoyproxybeat reads data from Envoy admin endpoint. For now, Envoyproxybeat collects non-dynamic statistics.

Document Example

  "envoyproxy": {

    "server": {

      "cluster_manager": {

        "warming_clusters": 0,

        "active_clusters": 1,

        "cluster_added": 1,

        "cluster_modified": 0,

        "cluster_removed": 0

      },

      "filesystem": {

        "write_buffered": 1,

        "write_completed": 1,

        "write_total_buffered": 0,

        "flushed_by_timer": 0,

        "reopen_failed": 0

      },

      "runtime": {

        "override_dir_exists": 0,

        "override_dir_not_exists": 0,

        "admin_overrides_active": 0,

        "load_error": 0,

        "load_success": 0,

        "num_keys": 0

      },

      "listener_manager": {

        "listener_added": 1,

        "listener_create_failure": 0,

        "listener_create_success": 4,

        "listener_modified": 0,

        "listener_removed": 0,

        "total_listeners_active": 1,

        "total_listeners_draining": 0,

        "total_listeners_warming": 0

      },

      "stats": {

        "overflow": 0

      },

      "server": {

        "live": 1,

        "memory_heap_size": 4194304,

        "watchdog_mega_miss": 0,

        "version": 4151803,

        "uptime": 15,

        "memory_allocated": 3168904,

        "parent_connections": 0,

        "days_until_first_cert_expiring": 2147483647,

        "watchdog_miss": 0,

        "total_connections": 0,

        "hot_restart_epoch": 0

      },

      "http2": {}

}

Go ile Komut Satırı Aracı Oluşturmak

CLI(Command Line Interface) -türkçe olarak ifade edersek komut satırı arayüzü- kullanıcıların komut satırında etkileşimde bulunduğu programdır.

Go standart kütüphanelerini kullanarak komut satırı araçları oluşturmanın basit bir yolunu sunuyor. Go'da bunu yapmanın birden çok yolu vardır ancak bu yazıda genel hatlarıyla flag paketini açıklayacağım.

Parametreleri Ayrıştırma

Ayrıştırma işleminde genel olarak kullanılan üç terim vardır; argümanlar, seçenekler ve bayraklar. Bunlar sıklıkla birbirinin yerine kullanılır.
Go bu terimler konusunda genel tanımlara uymuyor, flag paketi ile bir veya iki tire ile başlayan tüm dizgeleri bayrak olarak, kullanıcı girdisi ve tire olmayan tüm dizgeleri argüman olarak kabul ediyor. 

Flag Paketi

Flag paketi, komut satırı ayrıştırma işlemleri için kullanılan standart kütüphanedir.

Bayrakları, flag.String(), flag.Bool(), flag.Int() kullanılarak tanımlayabiliriz:

import "flag"
var ipPtr = flag.Int("bayrakAdı", 1234, "bayrakAdı için yardım mesajı")
flag.Parse()

ipPtr -bayrakAdı veya --bayrakAdı parametresi ile alınan değere referans gösterecektir. *ipPtr varsayılan değeri 1234'tür.
Bu örnekte flag.Parse() işlevi, komut satırı girişini ayrıştırır ve -bayrakAdı parametresi ile aldığı değeri *ipPtr'a yazar.

Bayrak olarak tanımlananlar birer işaretçilerdir.
Bayrağı Var() işlevi kullanarak bir değişkene bağlayabiliriz:

var ipdegeri int
flag.IntVar(&ipdegeri, "bayrakAdı", 1234, "bayrakAdı için yardım mesajı")
flag.Parse()

Kullanıcıdan aldığı cümlenin kaç kelimeden olduğunu döndüren basit bir go programı üzerinden flag paketini nasıl kullanacağımızı inceleyelim:

package main

import (
    "flag"
    "fmt"
    "os"
    "strings"
)

func main() {
    var cumle string
    flag.StringVar(&cumle, "boyut", "", "Cümlenin boyutunu döndürür.")
    flag.Parse()

    if cumle == "" {
        flag.PrintDefaults()
        os.Exit(1)
    }
    cumleBoyutu := kacKelime(cumle)
    fmt.Printf("Cumlenin kelime sayisi = %d \n", cumleBoyutu)

}

func kacKelime(cumle string) int {
    var kelimeler []string
    kelimeler = strings.Split(cumle, " ")
    return len(kelimeler)
}

Burada varsayılan değeri boş karakter dizgesi olan string türünde bir bayrak tanımlıyoruz. Eğer StringVar kullanıyorsak, değerin yazılacağı değişkenin adresini belirtmeliyiz. Son kısımda da kullanıcılara bu bayrağın ne işe yaradığını anlatmak için kullanım iletisi ekliyoruz.
Eğer kullanıcı herhangi bir parametre girmezse tanımlanan tüm komut satırı parametrelerinin kullanım iletisini yazdırır.
Eğer kullanıcı -boyut parametresi ile bir cümle yazarsa program girilen cümlenin kaç kelime olduğunu dönecektir.
Not: Programda string paketi cümleyi kelimelere bölmek, os paketi ise programın sonlanması için kullanılmıştır.
Son olarak bütün bayraklar tanımlandıktan sonra bayrakların değerlerinin atanması için flag.Parse() öğesini çağırmalıyız.

Help Çıktısı

Komut satırı aracınıza kullanıcıları nasıl çalıştıracağı konusunda yönlendiren bir mesaj eklemelisiniz. flag paketi bayrak oluştururken eklediğimiz kullanım iletilerini birleştirerek yardım metnini oluşturur.
Yardım metnini görüntülemek için:

./komutSatırıBayraklari --help

veya

./komutSatırıBayraklari -h

komutlarını kullanabiliriz.

help çıktısını kendimizde değiştirebiliriz, bunun için flag paketinde Usage işlevi bulunmaktadır.

package main

import (
    "flag"
    "fmt"
    "os"
)

func main() {
    flag.Usage = func() {
        fmt.Printf("%s programının yardım sayfasıdır.", os.Args[0])
        PrintDefaults()
    }
    flag.Parse()
}

Artık programımızı -h veya --help parametresiyle çalıştırdığımızda Usage ile oluşturduğumuz mesaj yazılacaktır.
Burada program adı yerine os.Args[0] kullanılmıştır çünkü ilk argüman her zaman programın adıdır.

Bir bayrağı zorunlu hale getirmek için:

    cumlePtr := flag.String("b", "", "Cümlenin boyutunu döndürür.(Kullanımı zorunludur.)")
    kontrolPtr := flag.Bool("k", false, "Doğru ya da yanlış değerini alır. Varsayılan değeri false.")
    flag.Parse()
    if *cumlePtr == "" {
        flag.PrintDefaults()
        os.Exit(1)
    }
    fmt.Printf("cumlePtr: %s,  kontrolPtr: %t", *cumlePtr, *kontrolPtr)

Burada -b parametresi olmadan program çalışmayacaktır.

Komut Satırından Çalıştırılabilir Hale Getirmek

$ go build gobayrak.go

Bu komut ile gobayrak adında çalıştırılabilir dosya oluşur.

$ cp gobayrak /usr/local/bin

Bu dosyayı /usr/local/bin dizinine kopyalarak programımızı komut satırından kullanabiliriz.

/etc/hosts Dosyası ve NSS Nedir?

Hosts Dosyası Nedir?

    Hosts dosyası makine adlarını IP adreslerine eşleyen, metin editörü ile açılıp düzenlenebilen bir işletim sistemi dosyasıdır. İnternet sitelerinin isimlerini IP adresleri ile eşleştirir de diyebiliriz.
Makine adları için statik bir tablo araması yapar.

• Makine adlarını çözümleme işlevinde, yerel sistemlerde kullanılmak üzere hosts dosyası herhangi bir makine adını veya alan adını tanımlamak için kullanılabilir.
• Bazı web servisleri, geliştiriciler veya yöneticiler şirketin iç kaynaklarına erişmek, bunları test etmek gibi çeşitli amaçlar için alanı sadece yerel alan ağı içinde tanımlar.
  Örneğin; sadece bir şirket içinde -şirketin yerel alan ağında- kullanılan bir panelimiz olsun. Bunu hosts dosyasında tanımlayarak bağlanabiliriz.
• Hosts dosyası çevrimiçi reklamcılığı, casus yazılımı, reklam yazılımı veya diğer kötü amaçlı yazılımları içerdiği bilinen zararlı kaynakların ve sunucuların etki alanlarını engellemek için kullanılabilir.
• DNS hizmetinde bir sorun, engel yada yönlendirme varsa hosts dosyasında belirli alan adlarını IP adresleriyle birlikte değiştirerek açık hale getirebiliriz.

Makine Adı ve IP Adreslerini Eşleme

    Hosts dosyası içerisinde her makine için tek satır ayrılmıştır ve bu satırların yazımı aşağıdaki formattadır:

IP_address    canonical_hostname    [aliases ...]

Dosya içerisinde;

• her alan bir boşluk karakteriyle veya tab karakteri ile birbirinden ayrılır.
• IP_address diye belirtilen alan, o makine adı için kullanılacak olan IP adresidir. 
• canonical_hostname ile belirtilen alan, IP adresiyle ilişkili yerel olarak bilinen sunucu adlarını belirtir. Genel yapıya göre IP adresinden sonraki ilk alan tam nitelikli alan adıdır. Yabi bu makinenin/sunucunun resmi adıdır. 
• aliases diye belirtilen diğer alanlar, tanımlanan IP adresi için diğer adlar veya alternatif adlardır.
• tamamen boş satırlar yok sayılır.

 /etc/hosts düz metin dosyasıdır ve iki türde satırlara izin verilir:

• Makine/sunucu adı tanımlaması
• Boş satırlar veya yorum satırları

Yorum sayırları '#' ile başlamalıdır.,

Hosts Dosyasının Konumu

    Dosya sistemi hiyerarşisi işletim sistemine göre değişir. Ancak bu dosya genellikle 'hosts' olarak isimlendirir.

Unix ve Unix-benzeri sistemlerde /etc/hosts konumunda bulunur. 

Örnek hosts dosyası:

       # The following lines are desirable for IPv4 capable hosts

       127.0.0.1       localhost

       # 127.0.1.1 is often used for the FQDN of the machine

       127.0.1.1       thishost.mydomain.org  thishost

       192.168.1.10    foo.mydomain.org       foo

       192.168.1.13    bar.mydomain.org       bar

       146.82.138.7    master.debian.org      master

       209.237.226.90  www.opensource.org

       # The following lines are desirable for IPv6 capable hosts

       ::1             localhost ip6-localhost ip6-loopback

       ff02::1         ip6-allnodes

       ff02::2         ip6-allrouters

    Bazı işletim sistemlerinde hosts dosyasının içeriği, DNS gibi diğer ad çözümleme yöntemleri için kullanılır ancak birçok sistem özelleştirme sağlamak için -Linux ve Unix için nsswitch.conf gibi-  

NSS (name server switch) kullanır. Uzak DNS çözümleyicisinin aksine, hosts dosyası yerel bilgisayar yöneticisinin doğrudan denetimi altındadır.

Peki Nedir Bu NSS?

    NSS ortak yapılandırma veritabanları ve ad çözümleme mekanizmaları için çeşitli kaynaklar sağlayan Unix-benzeri işletim sistemlerinde kullanılan bir servistir. Bu kaynaklar yerel işletim sistemi dosyalarını (/etc/group, /etc/passwd, /etc/hosts gibi), DNS, NIS ve LDAP'ı içerir.

NSS bir istemcinin veya uygulamanın ağ bilgilerini nasıl aldığını kontrol eder. 

nsswitch.conf dosyası ile yapılandırılabilir.

/etc/nsswitch.conf Dosyası

    Bu dosya GNU C kütüphanesi tarafından, çeşitli kategorilerde name-service hizmeti bilgileri elde etmek için hangi kaynaklardan ve hangi sırayla alınacağını belirlemek için kullanılan düz metin dosyasıdır. Bu yapılandırma dosyası, bir işlem -hosts, users, groups gibi- hakkında bilgi içeren çeşitli veritabanlarını nasıl incelediğini kontrol eder. Her bilgi kategorisi bir veritabanı adıyla tanımlanır. 

İlk sütun veritabanı adını belirtir. Kalan sütunlar, sorgulanacak kaynakların sırasını ve arama sonucuyla gerçekleşebilecek sınırlı bir eylemler kümesini tanımlar.

Sisteminizde desteklenen servis özellikleri, paylaşılan kütüphanelerin varlığına bağlıdır ve bu yüzden genişletilebilir. Örneğin hosts veritabanı için ek olarak 'dns', passwd ve shadow veritabanları için ek olarak 'compat' seçeneği belirtebilirsiniz.

    nsswitch.conf dosyasındaki her girdi, bir veritabanı adı ve ayrılmış kaynak listesinden oluşur. Her kaynak, bir sonraki listelenen kaynağın kullanılıp kullanılmayacağını belirleyen isteğe bağlı bir sonlandırma ölçütüne sahip olabilir veya arama mevcut kaynakta sona erer.

Örnek nsswitch.conf dosyası:

           passwd:         compat

           group:           compat

           shadow:        compat

           hosts:            dns [!UNAVAIL=return] files

           networks:      nis [NOTFOUND=return] files

           ethers:           nis [NOTFOUND=return] files

           protocols:     nis [NOTFOUND=return] files

           rpc:               nis [NOTFOUND=return] files

           services:       nis [NOTFOUND=return] files

New Metricbeat Module: Envoyproxy Module

Envoyproxy Module is a Metricbeat Module that collects metrics from Envoy Proxy and indexes them into Elasticsearch or Logstash.

Envoyproxy module is written in Golang like all Metricbeat Modules and Beats.

You can check out this blog post for more information about how to create a Metricbeat Module.

What is the Envoy Proxy?

Envoy is an L7 proxy and communication bus designed for large modern service-oriented architectures.

Envoy Stats

Envoy outputs numerous statistics which depend on how the server is configured. They can be seen locally via the /stats admin endpoint. The admin endpoint looks directly into the store to load all of the counters and gauges and print them.

Envoyproxy module reads data from Envoy admin endpoint. For now, Envoyproxy module collects non-dynamic statistics.

I have blogged in the past about "Envoy Proxy Statistics" and "Envoy Proxy Installation to Ubuntu 17.10".

Getting Started with Envoyproxy Module

Initially, you need to make Envoyproxy module enabled:

./metricbeat modules enable envoyproxy

You can see a list of enabled and disabled modules by running following command:

./metricbeat modules list

Then when you run Metricbeat, it loads the corresponding module configurations specified in the modules.d directory.
For more information, you can check [1].

Now Envoyproxy module is enabled and ready to collects metrics.

Configuration

Envoyproxy Module has some settings. If you want to change some config options adjust the modules.d/envoyproxy.yml file to your needs.

Here is a sample configuration:

- module: envoyproxy
  metricsets: ["server"]
  period: 10s
  hosts: ["localhost:9901"]

module: The name of the module to run.
metricsets: A list of metricsets to execute.(For now, envoyproxy module have one metricset)
period: How often the metricsets are executed. If a system is not reachable, Metricbeat returns an error for each period.
hosts: A list of hosts of fetch information from.

Metricsets

Envoyproxy module has one metricset; server.

Server Metricset

Server statistics describe how the Envoy server instance is working. Statistics like server uptime or amount of allocated memory are categorized here.

Metrics Collected

cluster_manager
Envoy’s cluster manager manages all configured upstream clusters. Just as the Envoy configuration can contain any number of listeners, the configuration can also contain any number of independently configured upstream clusters. The cluster manager has a statistics tree rooted at cluster_manager with the following statistics.

• active_clusters: Number of currently active (warmed) clusters. 
• cluster_added: Total clusters added (either via static config or CDS)
• cluster_modified: Total clusters modified (via CDS)
• cluster_removed: Total clusters removed (via CDS)
• warming_clusters: Number of currently warming (not active) clusters

filesystem
Statistics related to file system are emitted in the filesystem namespace.

• flushed_by_timer: Total number of times internal flush buffers are written to a file due to flush timeout
• reopen_failed: Total number of times a file was failed to be opened
• write_buffered: Total number of times file data is moved to Envoys internal flush buffer.
• write_completed: Total number of times a file was written.
• write_total_buffered: Current total size of internal flush buffer in bytes

runtime
The runtime configuration specifies the location of the local file system tree that contains re-loadable configuration elements. The file system runtime provider emits some statistics in the runtime namespace.

• load_error: Total number of load attempts that resulted in an error
• load_success: Total number of load attempts that were successful
• num_keys: Number of keys currently loaded
• override_dir_exists: Total number of loads that did use an override directory
• override_dir_not_exists: Total number of loads that did not use an override directory
• admin_overrides_active

listener_manager
The top level Envoy configuration contains a list of listeners. The listener manager has a statistics tree rooted at listener_manager with the following statistics.

• listener_added: Total listeners added (either via static config or LDS)
• listener_create_failure: Total failed listener object additions to workers
• listener_create_success: Total listener objects successfully added to workers
• listener_modified: Total listeners modified (via LDS)
• listener_removed: Total listeners removed (via LDS)
• total_listeners_active: Number of currently active listeners
• total_listeners_draining: Number of currently draining listeners
• total_listeners_warming: Number of currently warming listeners

stats
A few statistics are emitted to report statistics system behavior:

• overflow: Total number of times Envoy cannot allocate a statistic due to a shortage of shared memory

server
Server related statistics are rooted at server with following statistics:

• days_until_first_cert_expiring: Number of days until the next certificate being managed will expire
• live: 1 if the server is not currently draining, 0 otherwise
• memory_allocated: Current amount of allocated memory in bytes
• memory_heap_size: Current reserved heap size in bytes
• parent_connections: Total connections of the old Envoy process on hot restart
• total_connections: Total connections of both new and old Envoy processes
• uptime: Current server uptime in seconds
• version: Integer represented version number based on SCM revision
• watchdog_mega_miss
• watchdog_miss
• hot_restart_epoch: Current hot restart epoch

http2
Each codec has the option of adding per-codec statistics. Currently only http2 has codec stats. All http2 statistics are rooted at http2.

• header_overflow: Total number of connections reset due to the headers being larger than 63k
• headers_cb_no_stream: Total number of errors where a header callback is called without an associated stream. This tracks an unexpected occurrence due to an as yet undiagnosed bug
• rx_messaging_error: Total number of invalid received frames that violated section 8 of the HTTP/2 spec. This will result in a tx_reset
• rx_reset: Total number of reset stream frames received by Envoy
• too_many_header_frames: Total number of times an HTTP2 connection is reset due to receiving too many headers frames. Envoy currently supports proxying at most one header frame for 100-Continue one non-100 response code header frame and one frame with trailers
• trailers: Total number of trailers seen on requests coming from downstream
• tx_reset: Total number of reset stream frames transmitted by Envoy

Here is an example document generated by this metricset:

{
  "@timestamp": "2018-07-26T12:02:15.099Z",
  "@metadata": {
    "beat": "metricbeat",
    "type": "doc",
    "version": "7.0.0-alpha1"
  },
  "metricset": {
    "rtt": 11301,
    "name": "server",
    "module": "envoyproxy",
    "host": "localhost:9901"
  },
  "envoyproxy": {
    "server": {
      "cluster_manager": {
        "warming_clusters": 0,
        "active_clusters": 1,
        "cluster_added": 1,
        "cluster_modified": 0,
        "cluster_removed": 0
      },
      "filesystem": {
        "write_buffered": 1,
        "write_completed": 1,
        "write_total_buffered": 0,
        "flushed_by_timer": 0,
        "reopen_failed": 0
      },
      "runtime": {
        "override_dir_exists": 0,
        "override_dir_not_exists": 0,
        "admin_overrides_active": 0,
        "load_error": 0,
        "load_success": 0,
        "num_keys": 0
      },
      "listener_manager": {
        "listener_added": 1,
        "listener_create_failure": 0,
        "listener_create_success": 4,
        "listener_modified": 0,
        "listener_removed": 0,
        "total_listeners_active": 1,
        "total_listeners_draining": 0,
        "total_listeners_warming": 0
      },
      "stats": {
        "overflow": 0
      },
      "server": {
        "live": 1,
        "memory_heap_size": 4194304,
        "watchdog_mega_miss": 0,
        "version": 4151803,
        "uptime": 15,
        "memory_allocated": 3168904,
        "parent_connections": 0,
        "days_until_first_cert_expiring": 2147483647,
        "watchdog_miss": 0,
        "total_connections": 0,
        "hot_restart_epoch": 0
      },
      "http2": {}
    }
  },
  "host": {
    "name": "kripton"
  },
  "beat": {
    "name": "kripton",
    "hostname": "kripton",
    "version": "7.0.0-alpha1"
  }
}

Envoy Proxy Statistics

The first blog post introduced you to download Envoy Proxy with Docker image. In this second part, we will see how to get Envoy Proxy statistics.

Firstly, run it using docker run command:

docker run -d -p 8080:10000 -p 8081:9901 envoy:v1

Now admin console is available. This can be configured in json file inside admin property. I selected port 8081 and I had exposed that port outside Envoy Docker container.

If you invoke this command it returns all available commands: 

curl localhost:8081/

Now, running this command to get statistics: 

curl localhost:8081/stats

It returns server statistics. Look here for more information about Envoy Proxy statistics.

Example output:

cluster_manager.active_clusters: 1
cluster_manager.cluster_added: 1
cluster_manager.cluster_modified: 0
cluster_manager.cluster_removed: 0
cluster_manager.warming_clusters: 0
filesystem.flushed_by_timer: 0
filesystem.reopen_failed: 0
filesystem.write_buffered: 0
filesystem.write_completed: 0
filesystem.write_total_buffered: 0
http.admin.downstream_cx_active: 1
http.admin.downstream_cx_destroy: 0
http.admin.downstream_cx_destroy_active_rq: 0
http.admin.downstream_cx_destroy_local: 0
http.admin.downstream_cx_destroy_local_active_rq: 0
http.admin.downstream_cx_destroy_remote: 0
http.admin.downstream_cx_destroy_remote_active_rq: 0
http.admin.downstream_cx_drain_close: 0
http.admin.downstream_cx_http1_active: 1
http.admin.downstream_cx_http1_total: 1
http.admin.downstream_cx_http2_active: 0
http.admin.downstream_cx_http2_total: 0
http.admin.downstream_cx_idle_timeout: 0
http.admin.downstream_cx_protocol_error: 0
http.admin.downstream_cx_rx_bytes_buffered: 83
http.admin.downstream_cx_rx_bytes_total: 83
http.admin.downstream_cx_ssl_active: 0
http.admin.downstream_cx_ssl_total: 0
http.admin.downstream_cx_total: 1
http.admin.downstream_cx_tx_bytes_buffered: 0
http.admin.downstream_cx_tx_bytes_total: 0
http.admin.downstream_cx_websocket_active: 0
http.admin.downstream_cx_websocket_total: 0
http.admin.downstream_rq_1xx: 0
http.admin.downstream_rq_2xx: 0
http.admin.downstream_rq_3xx: 0
http.admin.downstream_rq_4xx: 0
http.admin.downstream_rq_5xx: 0
http.admin.downstream_rq_active: 1
http.admin.downstream_rq_http1_total: 1
http.admin.downstream_rq_http2_total: 0
http.admin.downstream_rq_non_relative_path: 0
http.admin.downstream_rq_response_before_rq_complete: 0
http.admin.downstream_rq_rx_reset: 0
http.admin.downstream_rq_too_large: 0
http.admin.downstream_rq_total: 1
http.admin.downstream_rq_tx_reset: 0
http.admin.downstream_rq_ws_on_non_ws_route: 0
http.admin.rs_too_large: 0
http.async-client.no_cluster: 0
http.async-client.no_route: 0
http.async-client.rq_direct_response: 0
http.async-client.rq_redirect: 0
http.async-client.rq_total: 0
http.ingress_http.downstream_cx_active: 0
http.ingress_http.downstream_cx_destroy: 0
http.ingress_http.downstream_cx_destroy_active_rq: 0
http.ingress_http.downstream_cx_destroy_local: 0
http.ingress_http.downstream_cx_destroy_remote: 0
http.ingress_http.downstream_cx_drain_close: 0
http.ingress_http.downstream_cx_http1_active: 0
http.ingress_http.downstream_cx_http1_total: 0
http.ingress_http.downstream_cx_http2_active: 0
http.ingress_http.downstream_cx_http2_total: 0
http.ingress_http.downstream_cx_idle_timeout: 0
http.ingress_http.downstream_cx_protocol_error: 0
http.ingress_http.downstream_cx_rx_bytes_buffered: 0
http.ingress_http.downstream_cx_rx_bytes_total: 0
http.ingress_http.downstream_cx_ssl_active: 0
http.ingress_http.downstream_cx_ssl_total: 0
http.ingress_http.downstream_cx_total: 0
http.ingress_http.downstream_cx_tx_bytes_buffered: 0
http.ingress_http.downstream_cx_tx_bytes_total: 0
http.ingress_http.downstream_cx_websocket_active: 0
http.ingress_http.downstream_cx_websocket_total: 0
http.ingress_http.downstream_rq_1xx: 0
http.ingress_http.downstream_rq_2xx: 0
http.ingress_http.downstream_rq_3xx: 0
http.ingress_http.downstream_rq_4xx: 0
http.ingress_http.downstream_rq_5xx: 0
http.ingress_http.downstream_rq_active: 0
http.ingress_http.downstream_rq_http1_total: 0
http.ingress_http.downstream_rq_http2_total: 0
http.ingress_http.downstream_rq_non_relative_path: 0
http.ingress_http.downstream_rq_rx_reset: 0
http.ingress_http.downstream_rq_too_large: 0
http.ingress_http.downstream_rq_total: 0
http.ingress_http.downstream_rq_tx_reset: 0
http.ingress_http.downstream_rq_ws_on_non_ws_route: 0
http.ingress_http.no_cluster: 0
http.ingress_http.no_route: 0
http.ingress_http.rq_direct_response: 0
http.ingress_http.rq_redirect: 0
http.ingress_http.rq_total: 0
http.ingress_http.rs_too_large: 0
http.ingress_http.tracing.client_enabled: 0
http.ingress_http.tracing.health_check: 0
http.ingress_http.tracing.not_traceable: 0
http.ingress_http.tracing.random_sampling: 0
http.ingress_http.tracing.service_forced: 0
listener.admin.downstream_cx_active: 1
listener.admin.downstream_cx_destroy: 0
listener.admin.downstream_cx_total: 1
listener.admin.http.admin.downstream_rq_1xx: 0
listener.admin.http.admin.downstream_rq_2xx: 0
listener.admin.http.admin.downstream_rq_3xx: 0
listener.admin.http.admin.downstream_rq_4xx: 0
listener.admin.http.admin.downstream_rq_5xx: 0
listener_manager.listener_added: 1
listener_manager.listener_create_failure: 0
listener_manager.listener_create_success: 0
listener_manager.listener_modified: 0
listener_manager.listener_removed: 0
listener_manager.total_listeners_active: 1
listener_manager.total_listeners_draining: 0
listener_manager.total_listeners_warming: 0
runtime.admin_overrides_active: 0
runtime.load_error: 0
runtime.load_success: 0
runtime.num_keys: 0
runtime.override_dir_exists: 0
runtime.override_dir_not_exists: 0
server.days_until_first_cert_expiring: 0
server.live: 1
server.memory_allocated: 0
server.memory_heap_size: 0
server.parent_connections: 0
server.total_connections: 0
server.uptime: 0server.version: 16364036
server.watchdog_mega_miss: 0
server.watchdog_miss: 0
stats.overflow: 0

Envoy Proxy Installation to Ubuntu 17.10

Envoy is an L7 proxy and communication bus designed for large modern service oriented architectures.

The easiest way to get started with Envoy by using the Docker images.
Create a Dockerfile:

FROM envoyproxy/envoy:latest
RUN apt-get update
COPY envoy.json /etc/envoy.json
CMD /usr/local/bin/envoy -c /etc/envoy.json

Create an envoy.json configuration file that describes your own Envoy configuration. You can check here for more information. Here is an example you can use those proxies incoming request to Google.com. You have to change the listener and admin to listen to 0.0.0.0 instead of 127.0.0.1 for this to work locally.


Build the Dockerfile:

docker build -t envoy:v1 .

Run the image, binding localhost port 8080 to the listener on port 10000 and localhost port 8081 to the admin on port 9901 specified in the envoy.json:

docker run -d -p 8080:10000 -p 8081:9901 envoy:v1

Test the image with curl:

curl localhost:8080 

curl localhost:8081

This blog post based on the Envoy Proxy download page.