Com os problemas listados acima, você precisará armazenar em buffer as estatísticas na extremidade remota para que nada seja perdido.

Há várias maneiras de fazer isso, mas nenhuma é excessivamente simples e exigirá muitos testes para garantir que sejam viáveis. Todos eles envolvem a gravação collectdda saída localmente e, em seguida, o uso de algum método para obtê-la no servidor central.

Eu não testei nenhum dos abaixo, então alguns podem não funcionar.

Em nenhuma ordem particular de facilidade ou complicação:

1. Socket/Network Output to Script
   Write Collectd's output to a socket or IP/port, where a PHP/Perl/Python/Bash script is listen to write the commands to a file.

   Esses arquivos podem então ser enviados/puxados pelo servidor central e ingeridos pelo Logstash.

   Prós : Script simples para capturar a saída; comandos padrão do Linux usados
   ​​Contras : Não escalável se você estiver obtendo muitas estatísticas; necessidade de manter o roteiro; não tenho certeza se LS lidará com protocolo simples

2. Redis/AMQP/Kafka/MongoDB Grava a Collectdsaída em um dos possíveis "buffers". Cada um deles funciona de maneira um pouco diferente e tem diferentes opções de implantação, então deixarei para você descobrir qual é o melhor, já que está fora do escopo desta pergunta. Dito isto, qualquer um deles deve funcionar.

   You'd then need a method to get the data from your buffer solution back to the Central Server. Application native Replication/Mirroring/Clustering or a script that runs every X interval to ship the data (run at either end) are two possibilities.

   Pros: Very flexible deployment options; should scale very well; uses well known tools/programs
   Cons: Buffer progam might need lots of resources, or many packages installed

3. Socket/Network Output to Logstash This is almost the same as option 1, but instead of having collectd output to a script/progarm, you have it write to a local Logstash instance on each Remote-Host.

   Logstash would then write to CSV/JSON locally, and you can use any means to get those files back to the Central Server, including LS itself.

   Pros: Single set of tools for whole solution; provides a way to transform data at the edge, then just ingest centrally; very few moving parts Cons: need Java/LS on all remote hosts

In addition to each options pros/cons, the single common downside to all of them is that you'd need to find a way to maintain consistent configs on all the servers. If you have lots of remote nodes (or just lots of nodes in general) you might already have a Configuration Management System in place and this will be trivial.

editar: Achtung! Aviso!

Por favor, use isso docker-composeem vez do que eu vinculei (requer dockere composetalvez machine, mas tenha feito mais por você e você terá que lutar menos.

CELK: https://github.com/codenamekt/celk-docker-compose/blob/master/logstash/logstash.conf

Também

Portanto, comece aqui para obter uma boa visão geral de um sistema em funcionamento. Eles fizeram parte do trabalho para você, então você precisa se preocupar apenas com sua pergunta, que diz respeito à configuração e implantação.

Mesmo que você acabe não usando o Docker, isso ainda o colocará no caminho do sucesso e terá o benefício adicional de mostrar como ele se encaixa.

Obtenha o Vagrant primeiro e construa a imagem Vagrant w/ vagrant up

Se você não sabe o que é Vagrant, é maravilhoso. É um programa que permite que as pessoas compartilhem todo o conjunto de máquinas virtuais e provisionadores para que você possa definir apenas uma VM e sua configuração, em vez de compartilhar toda a VM, e "simplesmente funciona". Parece mágico, mas na verdade é apenas um trabalho sólido de sistemas.

• (use o link acima para CELK): https://github.com/pblittle/docker-logstash

Você precisará instalar o Vagrant para usá-lo. Apenas faça! Então, você não precisa instalar dockerporque ele será executado em uma VM Vagrant.

Você tem quatro opções de como deseja usá-lo, mas primeiro prepare o Vagrant com o comando em negrito....

vagrant up

Decida quais programas você precisa executar

Suas opções são:

• Conjunto completo ou ELK (elasticsearch, logstash, kibana)
• Somente agente (coletor Logstash)
• somente Kibana

Existem outras configurações disponíveis, mas apenas para teste.

Altura de começar

Agora é hora de configurar o Logstash, que é realmente a única parte que possui comportamento complexo.

Os arquivos de configuração Logstash são arquivos de texto simples que terminam em confe, opcionalmente, podem ser agrupados usando um tarou gunzip gz.

Você obtém os arquivos de configuração de duas maneiras:

• você os baixa da Internet, usando a variável de ambiente LOGSTASH_CONFIG_URLpara apontar para o url de sua configuração e **se você errar o url ou houver algum problema e não conseguir obter uma configuração do url, ele voltará para um conhecido url ou então
• leia-os do disco, mais ou menos - já que este é o docker, você criará um volume uma vez (agora) e montará o volume toda vez que executar o contêiner.

Aqui está o que parece quando você executa usando uma configuração da Internet:

$ docker run -d \
  -e LOGSTASH_CONFIG_URL=https://secretlogstashesstash.com/myconfig.tar.gz \
  -p 9292:9292 \
  -p 9200:9200 \
  pblittle/docker-logstash

O autor do docker adverte :

O logstash.conf padrão atende apenas as entradas stdin e de arquivo. Se você deseja configurar a entrada tcp e/ou udp, use seus próprios arquivos de configuração logstash e exponha as portas por conta própria. Consulte a documentação do logstash para obter a sintaxe de configuração e mais informações.

Nota: Qual é o logstash conf padrão ?

Lembre-se de que é o arquivo que você obtém quando não coloca um URL correto para a variável de ambiente necessáriaLOGSTASH_CONFIG_URL

Esta é a seção de entrada:

// As the author warned, this is all you get. StdIn and Syslog file inputs.

input {
  stdin {
    type => "stdin-type"
  }

  file {
    type => "syslog"
    path => [ "/var/log/*.log", "/var/log/messages", "/var/log/syslog" ]
  }

  file {
    type => "logstash"
    path => [ "/var/log/logstash/logstash.log" ]
    start_position => "beginning"
  }
}

além do padrão

Leia mais sobre logstashno site.

Agora logstashtem plug-ins que enviam dados para arquivos input. Os plugins variam exatamente como você esperaria; aqui estão alguns:

• s3da amazon (eventos do sistema de arquivos)
• stdinfrom logstash(padrão, lê o stdinbuffer)
• httpde logstash(seu palpite)
• ...etc...

Exemplo: soquetes UDP

UDPé um protocolo sem conexão e rápido que opera na parte inferior do L4(transporte) e oferece suporte à multiplexação, lida com falhas e geralmente é uma boa escolha para registrar a transmissão de dados.

Você escolhe a porta que deseja; outras opções dependem do que você está fazendo.

O TCP funciona da mesma maneira.

udp { porta => 9999 codec => json buffer_size => 1452 }

Exemplo 2: soquetes UDP collectdfiltrados e de saída

This is stolen from https://github.com/codenamekt/celk-docker-compose/blob/master/logstash/logstash.conf

input {
  udp {
    port => 25826         # 25826 matches port specified in collectd.conf
    buffer_size => 1452   # 1452 is the default buffer size for Collectd
    codec => collectd { } # specific Collectd codec to invoke
    type => collectd
  }
}
output {
  elasticsearch {
    host => elasticsearch
    cluster  => logstash
    protocol => http
  }
}

E a filtragem é um ótimo exemplo: Ou seja, é muito longo e acho que faz coisas

filter {
  # TEST implementation of parse for collectd
  if [type] == "collectd" {
    if [plugin] {
      mutate {
        rename => { "plugin" => "collectd_plugin" }
      }
    }
    if [plugin_instance] {
      mutate {
        rename => { "plugin_instance" => "collectd_plugin_instance" }
      }
    }
    if [type_instance] {
      mutate {
        rename => { "type_instance" => "collectd_type_instance" }
      }
    }
    if [value] {
      mutate {
        rename => { "value" => "collectd_value" }
      }
      mutate {
        convert => { "collectd_value" => "float" }
      }
    }
    if [collectd_plugin] == "interface" {
      mutate {
        add_field => {
          "collectd_value_instance" => "rx"
          "collectd_value" => "%{rx}"
        }
      }
      mutate {
        convert => {
          "tx" => "float"
          "collectd_value" => "float"
        }
      }
      # force clone for kibana3
      clone {
        clones => [ "tx" ]
      }
      ##### BUG EXISTS : AFTER clone 'if [type] == "foo"' NOT WORKING : ruby code is working #####
      ruby {
        code => "
          if event['type'] == 'tx'
            event['collectd_value_instance'] = 'tx'
            event['collectd_value'] = event['tx']
          end
        "
      }
      mutate {
        replace => { "_type" => "collectd" }
        replace => { "type" => "collectd" }
        remove_field => [ "rx", "tx" ]
      }
    }
    if [collectd_plugin] == "disk" {
      mutate {
        add_field => {
          "collectd_value_instance" => "read"
          "collectd_value" => "%{read}"
        }
      }
      mutate {
        convert => {
          "write" => "float"
          "collectd_value" => "float"
        }
      }
      # force clone for kibana3
      clone {
        clones => [ "write" ]
      }
      ##### BUG EXISTS : AFTER clone 'if [type] == "foo"' NOT WORKING : ruby code is working #####
      ruby {
        code => "
          if event['type'] == 'write'
             event['collectd_value_instance'] = 'write'
             event['collectd_value'] = event['write']
          end
        "
      }
      mutate {
        replace => { "_type" => "collectd" }
        replace => { "type" => "collectd" }
        remove_field => [ "read", "write" ]
      }
    }
    if [collectd_plugin] == "df" {
      mutate {
        add_field => {
          "collectd_value_instance" => "free"
          "collectd_value" => "%{free}"
        }
      }
      mutate {
        convert => {
          "used" => "float"
          "collectd_value" => "float"
        }
      }
      # force clone for kibana3
      clone {
        clones => [ "used" ]
      }
      ##### BUG EXISTS : AFTER clone 'if [type] == "foo"' NOT WORKING : ruby code is working  #####
      ruby {
        code => "
          if event['type'] == 'used'
            event['collectd_value_instance'] = 'used'
            event['collectd_value'] = event['used']
          end
        "
      }
      mutate {
        replace => { "_type" => "collectd" }
        replace => { "type" => "collectd" }
        remove_field => [ "used", "free" ]
      }
    }
    if [collectd_plugin] == "load" {
      mutate {
        add_field => {
          "collectd_value_instance" => "shortterm"
          "collectd_value" => "%{shortterm}"
        }
      }
      mutate {
        convert => {
          "longterm" => "float"
          "midterm" => "float"
          "collectd_value" => "float"
        }
      }
      # force clone for kibana3
      clone {
        clones => [ "longterm", "midterm" ]
      }
      ##### BUG EXISTS : AFTER clone 'if [type] == "foo"' NOT WORKING : ruby code is working #####
      ruby {
        code => "
          if event['type'] != 'collectd'
            event['collectd_value_instance'] = event['type']
            event['collectd_value'] = event[event['type']]
          end
        "
      }
      mutate {
        replace => { "_type" => "collectd" }
        replace => { "type" => "collectd" }
        remove_field => [ "longterm", "midterm", "shortterm" ]
      }
    }
  }
}

editar 3: Eu provavelmente não deveria estar fazendo o seu trabalho para você, mas tudo bem.

collectdcomo qualquer bom software ENCAPSULTAES certos aspectos que são feios ou difíceis para os usuários lidarem, e tenta facilitar para você parecer que você está enviando dados (uma tupla neste caso) em vez de brincar com a serialização.

Seu exemplo:

(date_time, current_cpu_load), for example ('2016-0-04-24 11:09:12', 12.3)

Não vou gastar meu tempo tentando descobrir como você está formando isso. Se você conseguir obter esses dados usando o plug-in da CPU, ótimo. Vou copiar e colar um que encontrei online para facilitar.

Dito isso, pense bem... só um pouquinho, não vai doer.

Você vê que o plug-in da CPU está carregado abaixo.

Você vê que a interface collectddo confarquivo é muito pequena para especificar campos.

Portanto, se você apenas fizer isso, funcionará, mas obterá muito mais dados do que apenas a carga da CPU.

É aí que você pode usar um filtro. Mas você também pode fazer isso em Kibana, eu acho. Portanto, prefiro não perder tempo escrevendo um filtro que você a) não precisa e b) poderia escrever facilmente se gastasse algum tempo.

## In `collectd`:
# For each instance where collectd is running, we define 
# hostname proper to that instance. When metrics from
# multiple instances are aggregated, hostname will tell 
# us were they came from.
Hostname "**YOUR_HOSTNAME**"


    # Fully qualified domain name, false for our little lab
    FQDNLookup false

    # Plugins we are going to use with their configurations,
    # if needed
    LoadPlugin cpu

    LoadPlugin df
    <Plugin df>
            Device "/dev/sda1"
            MountPoint "/"
            FSType "ext4"
            ReportReserved "true"
    </Plugin>

    LoadPlugin interface
    <Plugin interface>
            Interface "eth0"
            IgnoreSelected false
    </Plugin>

    LoadPlugin network
    <Plugin network>
            Server "**YOUR.HOST.IP.ADDR**" "**PORTNUMBER**"
    </Plugin>

    LoadPlugin memory

    LoadPlugin syslog
    <Plugin syslog>
            LogLevel info
    </Plugin>

    LoadPlugin swap

    <Include "/etc/collectd/collectd.conf.d">
            Filter ".conf"
    </Include>

Sua configuração de logstash

    input {
      udp {
        port => **PORTNUMBER**         # 25826 matches port specified in collectd.conf
        buffer_size => **1452**   **# 1452 is the default buffer size for Collectd**
        codec => collectd { } # specific Collectd codec to invoke
        type => collectd 
      }
    }
    output {
      elasticsearch {
        cluster  => **ELASTICSEARCH_CLUSTER_NAME** # this matches out elasticsearch cluster.name
        protocol => http
      }
    }

uma atualização de aaron em collectd

No Logstash 1.3.x, introduzimos o plugin de entrada collectd. Foi incrível! Poderíamos processar métricas no Logstash, armazená-las no Elasticsearch e visualizá-las com o Kibana. A única desvantagem era que você só conseguia cerca de 3100 eventos por segundo por meio do plug-in. Com o Logstash 1.4.0, introduzimos um plug-in de entrada UDP recém-renovado que era multiencadeado e tinha uma fila. Eu refatorei o plugin de entrada collectd para ser um codec (com alguma ajuda de meus colegas de trabalho e da comunidade) para aproveitar esse enorme aumento de desempenho. Agora, com apenas 3 threads no meu Macbook Air dual-core, posso obter mais de 45.000 eventos por segundo através do codec collectd!

Portanto, gostaria de fornecer alguns exemplos rápidos que você poderia usar para alterar a configuração do plug-in para usar o codec.

O jeito antigo: input { collectd {} } O jeito novo:

input {   udp {
port => 25826         # Must be specified. 25826 is the default for collectd
buffer_size => 1452   # Should be specified. 1452 is the default for recent versions of collectd
codec => collectd { } # This will invoke the default options for the codec
type => "collectd"   } } This new configuration will use 2 threads and a queue size of 2000 by default for the UDP input plugin. With
this you should easily be able to break 30,000 events per second!

Forneci uma essência com alguns outros exemplos de configuração. Para obter mais informações, consulte a documentação do Logstash para o codec collectd.

Logstashing feliz!