Amazon Cloudwatch only receiving mem_used_percent and nothing else, despite numerous other metrics specified in config - amazon-cloudwatch

I am trying to get CloudWatch running properly on my Lightsail instance, which I appear to achieved with only partial success.
I have ran the Wizard using sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard which has produced a config file outlining numerous metrics including cpu, memory and disk usage as outlined here. The service loads and starts the config file, and doesn't complain about invalid json (this did happen a few times, but I fixed it).
I can stop the service with sudo amazon-cloudwatch-agent-ctl -a stop
I then reload the config with sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -s -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json
Verify the service is running: sudo amazon-cloudwatch-agent-ctl -a status
Which outputs this:
{
"status": "running",
"starttime": "2022-01-10T21:53:12+00:00",
"configstatus": "configured",
"cwoc_status": "stopped",
"cwoc_starttime": "",
"cwoc_configstatus": "not configured",
"version": "1.247349.0b251399"
}
Logging into my CloudWatch console, I can see the data being received, and the single line appearing on the graph there corresponds to the times that I started and stopped the service-- so it's definitely doing something. And yet... the only metric that appears on that graph is mem_used_percent... why? Why only this one metric? Where is the rest of my data pertaining to cpu, etc? What am I doing wrong?
Here is my config.json, which as I said, is being loaded by the service without issue.
{
"agent": {
"metrics_collection_interval": 60,
"run_as_user": "root"
},
"metrics": {
"append_dimensions": {
"ImageID": "${aws:ImageId}",
"InstanceId":"${aws:InstanceId}",
"InstanceType":"${aws:InstanceType}"
},
"metrics_collected": {
"cpu": {
"resources": [
"*"
],
"measurement": [
"cpu_usage_active"
],
"metrics_collection_interval": 60,
"totalcpu": false
},
"disk": {
"measurement": [
"free",
"total",
"used",
"used_percent"
],
"metrics_collection_interval": 60,
"resources": [
"*"
]
},
"mem": {
"measurement": [
"mem_active",
"mem_available",
"mem_available_percent",
"mem_free",
"mem_total",
"mem_used",
"mem_used_percent"
],
"metrics_collection_interval": 60
},
"netstat": {
"measurement": [
"tcp_established",
"udp_socket"
]
}
}
}
}
Any help greatly appreciated here. TIA.

You likely haven't fetched the configuration yet.
Check the logfile, i.e. /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log, to see which inputs are loaded:
2022-05-18T10:18:57Z I! Loaded inputs: mem disk
To fetch the configuration, do as follows (you'll need to adapt this to your environment - this is for systemd, on-premise, without SSM):
sudo amazon-cloudwatch-agent-ctl -a fetch-config -m onPremise -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json
sudo systemctl status amazon-cloudwatch-agent.service restart
After:
2022-05-18T11:45:05Z I! Loaded inputs: mem net netstat swap cpu disk diskio

Maybe you face the same issue as I did. In my case two configuration json files
/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/file_config.json
/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json
were merged.
The files are then translated to
/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml.
When I was checking the file, only the mem definition of /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/file_config.json was taken. Thus, I deleted the file and restarted the service.
sudo systemctl restart amazon-cloudwatch-agent
After the restart, the toml file contained what I expected and the metrics were in place.

Related

Windows Terminal profile not showing up

I've just installed WSL2 and am using the Windows Terminal on Win10 1909 (18363.1256). I'm trying to set up 2 different profiles, one that launches a local WSL2 Ubuntu shell, and one that launches another WSL2 shell that will automatically ssh to a specific host.
The local one works great, shows up without an issue, however I can't seem to get my 2nd profile to show up in the list of profiles.
My settings.json looks like this:
"profiles":
{
"defaults":
{
// Put settings here that you want to apply to all profiles.
"colorScheme": "One Half Dark",
"fontFace": "JetbrainsMono NF",
"fontSize": 11
},
"list":
[
{
"guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
"hidden": false,
"name": "Ubuntu",
"source": "Windows.Terminal.Wsl",
"startingDirectory": "//wsl$/Ubuntu/home/sensanaty",
"tabTitle": "WSL2"
},
{
"guid": "{15c5814b-7ed1-4cec-bc64-d165274958fa}",
"hidden": false,
"name": "External Host",
"source": "Windows.Terminal.Wsl",
"commandline": "ssh example#123.456.7.89",
"tabTitle": "External Host"
},
]
},
With the above, I only get the Ubuntu profile in my list
I thought maybe it was the guid generated or something, but I just did a simple uuidgen and pasted it into the json so it shouldn't really be causing any issues there. I've also obviously tried restarting my system, to no avail. The default profiles show up fine if I disable the option to stop auto-generating them, as well.
Any clue as to what might help me out?
The 'source' attribute is for dynamically generated profiles, for which WSL will create one for each instance installed. You can't control the command line for these dynamically generated profiles. What you need is for your new profile to extend the command line to tell Terminal to use WSL. Remove the 'source' attribute entirely, so that your new profile is static.
In your case, that should be ...
{
"guid": "{15c5814b-7ed1-4cec-bc64-d165274958fa}",
"hidden": false,
"name": "External Host",
//"source": "Windows.Terminal.Wsl",
"commandline": "wsl.exe ssh example#123.456.7.89",
"tabTitle": "External Host"
}//,
As bwolfbarn mentioned, you should also ditch that trailing comma if it really comes at the end of the "list" block.
Here are a few lines from mine as additional examples as well ...
{
"guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
"hidden": false,
"name": "Ubuntu 20.04 WSL2 tmux",
//"source": "Windows.Terminal.Wsl",
"commandline": "wsl.exe -d Ubuntu -e sh -c \"/usr/bin/tmux has-session -t main 2>/dev/null && /usr/bin/tmux attach-session -d -t main || /usr/bin/tmux -2 new-session -t main -s main -c ${HOME}\"",
"cursorShape": "filledBox"
},
{
"guid": "{4e04fa7e-76c7-4746-a322-a227e70dde6c}",
"hidden": false,
"name": "Ubuntu 20.04 WSL1 tmux",
//"commandline": "wsl.exe -d Ubuntu20.04_WSL1",
"commandline": "wsl.exe -d Ubuntu20.04_WSL1 -e sh -c \"/usr/bin/tmux has-session -t main 2>/dev/null && /usr/bin/tmux attach-session -d -t main || /usr/bin/tmux -2 new-session -t main -s main -c ${HOME}\"",
"cursorShape": "filledBox"
}
Note that you could, I believe, use "wsl.exe -e" (a.k.a. --execute), but it's not really necessary in your case.
If you want to see your "source": "Windows.Terminal.Wsl" in Windows Terminal Menu it must exist in the registry
[HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss\{UUID}]
(The registry UUID is not related to Windows Terminal UUID).
This registry entry can be created by running "wsl --import" or by cloning existing entry (if you are comfortable messing with the registry).
If you still don't see your profile after confirming that the registry entry exists, remove all entries for "generatedProfiles" in state.json file located in the same folder as settings.json. This will force Windows Terminal to update state.json. If you generated Windows Terminal profile UUID yourself, it may ignore it and create its own one. In this case you will see duplicate entries for the profile in settings.json. Remove the ones that were generated manually, and leave the one generated by the terminal.
At least the last comma should be removed (I commented it in your example) as the element "External Host" is the last of the list.
[
{
"guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
"hidden": false,
"name": "Ubuntu",
"source": "Windows.Terminal.Wsl",
"startingDirectory": "//wsl$/Ubuntu/home/sensanaty",
"tabTitle": "WSL2"
},
{
"guid": "{15c5814b-7ed1-4cec-bc64-d165274958fa}",
"hidden": false,
"name": "External Host",
"source": "Windows.Terminal.Wsl",
"commandline": "ssh example#123.456.7.89",
"tabTitle": "External Host"
}//,
]

Packer ssh timeout

I am trying to build images with packer in a jenkins pipeline. However, the packer ssh provisioner does not work as the ssh never becomes available and error out with timeout.
Farther investigation of the issue shows that, the image is missing network interface files ifconfig-eth0 in /etc/sysconfig/network-scripts directory so it never gets an ip and does not accept ssh connection.
The problem is, there are many such images to be generated and I can't open each one manually in GUI of virtualbox and correct the issue and repack. Is there any other possible solution to that?
{
"variables": {
"build_base": ".",
"isref_machine":"create-ova-caf",
"build_name":"virtual-box-jenkins",
"output_name":"packer-virtual-box",
"disk_size":"40000",
"ram":"1024",
"disk_adapter":"ide"
},
"builders":[
{
"name": "{{user `build_name`}}",
"type": "virtualbox-iso",
"guest_os_type": "Other_64",
"iso_url": "rhelis74_1710051533.iso",
"iso_checksum": "",
"iso_checksum_type": "none",
"hard_drive_interface":"{{user `disk_adapter`}}",
"ssh_username": "root",
"ssh_password": "Secret1.0",
"shutdown_command": "shutdown -P now",
"guest_additions_mode":"disable",
"boot_wait": "3s",
"boot_command": [ "auto<enter>"],
"ssh_timeout": "40m",
"headless":
"true",
"vm_name": "{{user `output_name`}}",
"disk_size": "{{user `disk_size`}}",
"output_directory":"{{user `build_base`}}/output-{{build_name}}",
"format": "ovf",
"vrdp_bind_address": "0.0.0.0",
"vboxmanage": [
["modifyvm", "{{.Name}}","--nictype1","virtio"],
["modifyvm", "{{.Name}}","--memory","{{ user `ram`}}"]
],
"skip_export":true,
"keep_registered": true
}
],
"provisioners": [
{
"type":"shell",
"inline": ["ls"]
}
]
}
When you don't need the SSH connection during the provisioning process you can switch it off. See the packer documentation about communicator, there you see the option none to switch of the communication between host and guest.
{
"builders": [
{
"type": "virtualbox-iso",
"communicator": "none"
}
]
}
Packer Builders DOCU virtualbox-iso

How to configure Sensu with RMQ and InfluxDB

I am trying to get started with a monitoring server solution. I got the Sensu Clients, RabbitMQ and Uchiwa configured but then I tried using Graphite but there were so many parts to configure I tried InfluxDB instead. I am stuck configuring Sensu to InfluxDB.
Is there a part missing in the below configuration?
Client [Sensu] > RabbitMQ <> Sensu Server <> InfluxDB <> Grafana
Any suggestions?
cat influx.json
{
"influxdb": {
"hosts" : ["192.168.1.1"],
"host" : "192.168.1.1",
"port" : "8086",
"database" : "sensumetrics",
"time_precision": "s",
"use_ssl" : false,
"verify_ssl" : false,
"initial_delay" : 0.01,
"max_delay" : 30,
"open_timeout" : 5,
"read_timeout" : 300,
"retry" : null,
"prefix" : "",
"denormalize" : true,
"status" : true
}
}
cat handler.json
{
"handlers": {
"influxdb": {
"type": "pipe",
"command": "/opt/sensu/embedded/bin/metrics-influxdb.rb"
}}}
checks1,
{
"checks": {
"check_memory_linux": {
"handlers": ["influxdb","default"],
"command": "/opt/sensu/embedded/bin/check-memory-percent.rb -w 90 -c 95",
"interval": 60,
"occurrences": 5,
"subscribers": [ "TEST" ]
}}}
checks2,
{
"checks": {
"check_cpu_linux-elkctrl-pipe": {
"type": "metric",
"command": "/opt/sensu/embedded/bin/check-cpu.rb -w 80 -c 90",
"subscribers": ["TEST"],
"interval": 10,
"handlers": ["debug","influxdb"]
}}}
To use InfluxDB to persist your data, you must have:
InfluxDB plugin installed (also, installation and usage instructions here)
Definitions for the plugin (an influxdb.json containin at least the host, port, user, password and database to be used by Sensu)
The definition, as other config files, must be in /etc/sensu/conf.d/
Handler configuration set properly (also in conf.d)
Mutator for InfluxDB (extensions)
Your checks must send results to the handler, so their definition must contain:
"handlers": [
"influxdb"
]
Or whatever name you gave your handler.
Case, if the influxdb config you provided above is the full extent of your configuration, it would seem to be missing the username/password attributes required by the influxdb configuration. If they're present, but not provided in the post, no big deal. However, I'd recommend doing the following for your Sensu logs:
grep -i influxdb /var/logs/sensu/sensu-server.log
And seeing if the check result is getting sent to your influxdb instance. If they are, you should be receiving an error that might be pointing a bit more to what's going on.
You can also check your influxdb logs to see if they're getting a post from your Sensu server:
journalctl -u influxdb.service -f
But yeah, if the username/password is missing from the configuration, that'd be the first place that I start.

how to consume rest api of apache nutch docker

I pulled and started apache nutch docker
started it with
docker run --name my_nutch -d -p 8899:8899 -e SOLRURL=192.168.99.100:8983 -t meabed/nutch
any action I try to consume (according to their rest api) - I get 404
for example
192.168.99.100:8899/admin
tried also
GET http://192.168.99.100:8899/nutch/#/admin
I get in postman (for all GET REST requests, POST I get 404)
[
[
"admin",
"Service admin actions"
],
[
"confs",
"Configuration manager"
],
[
"db",
"DB data streaming"
],
[
"jobs",
"Job manager"
]
]

Durandal.js optimizer not working (empty main-built.js)

I'm trying to get Durandal.js optimizer working on my test project, but it seems to generate nothing to main-built.js. I use the following command from node.js command prompt, in durandal/amd folder:
optimizer.exe --verbose true
Result is
Using default base configuration.
Configuring for deploy with almond (custom).
{
"name": "durandal/amd/almond-custom",
"inlineText": true,
"stubModules": [
"durandal/amd/text"
],
"paths": {
"text": "durandal/amd/text"
},
"baseUrl": "C:\\Users\\Tommi Gustafsson\\Documents\\Visual Studio 2012\\Projects\\DurandalTests\\DurandalTest1\\TestApp",
"mainConfigFile": "C:\\Users\\Tommi Gustafsson\\Documents\\Visual Studio 2012\\Projects\\DurandalTests\\DurandalTest1\\TestApp\\main.js",
"include": [
"main-built",
"main",
"bindings/tinymce-binding",
"durandal/app",
"durandal/composition",
"durandal/events",
"durandal/http",
"text!durandal/messageBox.html",
"durandal/messageBox",
"durandal/modalDialog",
"durandal/system",
"durandal/viewEngine",
"durandal/viewLocator",
"durandal/viewModel",
"durandal/viewModelBinder",
"durandal/widget",
"durandal/plugins/router",
"durandal/transitions/entrance",
"raphael-amd/eve.0.3.4",
"raphael-amd/raphael.2.1.0.amd",
"raphael-amd/raphael.2.1.0.core",
"raphael-amd/raphael.2.1.0.svg",
"raphael-amd/raphael.2.1.0.vml",
"viewmodels/flickr",
"viewmodels/modal1",
"viewmodels/myPage",
"viewmodels/shell",
"viewmodels/welcome",
"text!views/detail.html",
"text!views/flickr.html",
"text!views/modal1.html",
"text!views/myPage.html",
"text!views/shell.html",
"text!views/welcome.html"
],
"exclude": [],
"keepBuildDir": true,
"optimize": "uglify2",
"out": "C:\\Users\\Tommi Gustafsson\\Documents\\Visual Studio 2012\\Projects\\DurandalTests\\DurandalTest1\\TestApp\\main-built.js",
"pragmas": {
"build": true
},
"wrap": true,
"insertRequire": [
"main"
]
}
Deleting old output file.
Tracing dependencies for: durandal/amd/almond-custom
Then, when I check main-built.js, it is empty. Can anyone help me what is the problem? I have several AMD modules in the test project, including Raphael.js AMD modules.
My requirejs configuration looks like this:
requirejs.config({
paths: {
'text': 'durandal/amd/text',
'eve': './raphael-amd/eve.0.3.4',
'raphael.core': './raphael-amd/raphael.2.1.0.core',
'raphael.svg': './raphael-amd/raphael.2.1.0.svg',
'raphael.vml': './raphael-amd/raphael.2.1.0.vml',
'raphael': './raphael-amd/raphael.2.1.0.amd',
'tinymce': "../Scripts/tinymce/jquery.tinymce.min"
}
});
In the same amd folder, where optimizer is stored, try running node r.js -o app.build.js. I've seen r.js sometimes choke about some dependencies, which resolves without problem when loading via require.js. For whatever reason the error messages won't show up when using optimizer --verbose. Typically the error message provides enough information to see where this occurs and if you've to update require.contig.paths or a specific define dependency.