Только начинаю работать с новой установкой ELK (никогда раньше не использовал, просто пытаюсь изучить). У меня Logstash 2.2.4 работает на ubuntu 14.04 LTS.
После размещения файла yaml с учетными данными пользователя AWS моего монитора (политика, настроенная в соответствии с документацией посредством копирования / вставки), я создал следующий файл .conf в /etc/logstash/conf.d:
input {
cloudwatch {
metrics => ["CPUUtilization"]
filters => { "tag:Monitoring" => "Yes" }
region => "us-east-1"
namespace => "AWS/EC2"
aws_credentials_file => "/var/opt/aws.yaml"
}
}
output {
elasticsearch {
hosts => ["localhost:9200"]
}
}
У меня есть три сервера в us-east-1 с тегом «Monitoring», установленным на «Yes», но когда я просматриваю свои журналы logstash, возникает ошибка, что нет никаких показателей для запроса. Пример записи об ошибке (отформатирован для удобства чтения):
{
:timestamp=>"2016-10-31T13:38:06.314000-0400",
:message=>"A plugin had an unrecoverable error. Will restart this plugin.\n
Plugin: <LogStash::Inputs::CloudWatch
metrics=>[\"CPUUtilization\"],
filters=>{\"tag:Monitoring\"=>\"Yes\"},
region=>\"us-east-1\",
namespace=>\"AWS/EC2\",
aws_credentials_file=>\"/var/opt/aws.yaml\",
codec=><LogStash::Codecs::Plain charset=>\"UTF-8\">,
use_ssl=>true,
statistics=>[\"SampleCount\", \"Average\", \"Minimum\", \"Maximum\", \"Sum\"],
interval=>900,
period=>300,
combined=>false>\n Error: No metrics to query", :level=>:error}
РЕДАКТИРОВАТЬ
На основании комментария я обновил свою политику для пользователя службы, учетные данные которого находятся в вышеупомянутом файле .yaml. Это не повлияло на поведение, вот как сейчас выглядит моя политика:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1444715676000",
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics"
],
"Resource": "*"
},
{
"Sid": "Stmt1444716576170",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeTags"
],
"Resource": "*"
}
]
}
Проверяя, правильно ли я назначил политику пользователю, я заметил, что в какой-то момент отладки я также назначил политику CloudWatchReadOnlyAccess, которая выглядит так (на случай, если что-то сломается):
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"autoscaling:Describe*",
"cloudwatch:Describe*",
"cloudwatch:Get*",
"cloudwatch:List*",
"logs:Get*",
"logs:Describe*",
"logs:TestMetricFilter",
"sns:Get*",
"sns:List*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
На самом деле это мой первый раз, когда я использую что-то отличное от заранее определенных политик, поэтому я думаю, что, возможно, я что-то пропустил при написании этого.
В документации не говорится, что вам нужно установить еще несколько прав для использования фильтров. Код выполняет описать экземпляры позвоните в свой аккаунт, используя filters чтобы получить список идентификаторов экземпляров, который затем запускает API-интерфейс cloudwatch.
Политика IAM, указанная в документации, распространяется только на вызовы API Cloudwatch. Если вы полностью отключили фильтры в своей конфигурации, ты бы получил данные.
Однако вы хотите фильтровать по тегам. Для этого вам понадобится как минимум:
ec2:DescribeInstances
ec2:DescribeTags
В операторе разрешения, чтобы иметь возможность получить нужные вам данные.
Чтобы устранить эту проблему, я бы проверил, что учетные данные AWS делают то, что должны, чтобы исключить это. AWS CLI эквивалент того, что они делают:
aws ec2 describe-instances --filters "Name=tag:Monitoring,Value=Yes"
Если это не удается, то это ваша проблема. Вам может понадобиться ec2:DescribeNetworkInterfaces тоже, но я не уверен в этом.
Если это удастся, значит проблема не в ваших правах EC2, а в другом. Вы можете воспроизвести вызов, который плагин делает в cloudwatch, следующим образом:
aws cloudwatch list-metrics --namespace AWS/EC2 --dimensions "Name=InstanceId,Value=i-1234abcd" --metric-name CPUUtilization
Плагин использует describe-instances позвонить, чтобы получить InstanceId значения для экземпляров с тегом Monitoring.
Если это работает, как и выборка экземпляра, значит, проблема связана с плагином. Убедитесь, что файл учетных данных действительно доступен для чтения процессом logstash. Вы можете обойтись без поиска тегов, попытавшись получить определенный экземпляр. В коде есть пример как это указать.
filters => { 'instance-id' => 'i-1234abcd' }