of observability and security platform renowned for providing comprehensive, full-stack visibility across complex IT infrastructures. Its primary strengths lie in consolidating multiple monitoring functions, offering vast integration capabilities, and accelerating incident resolution through AI-powered analytics
Friday, May 15, 2026
Monday, September 29, 2025
Trusted Advisor Adv Management
Deep Dive and Advance Management @Squatch Talks
- Trusted Advisor Offers a visualization dashboard with QuikSight
- Trusted Advisor APIs can be used to get a list of checks, recommendations, and resources for recommendations.
- You can use TA APIs for your infrastructure automation and audits you want to build
Sunday, September 28, 2025
ebsnvme-id output not consistent
[root]# rpm -qf /sbin/ebsnvme-id
ec2-utils-1.0-2.amzn2.noarch
[root]# ebsnvme-id -b /dev/nvme0n1 xvda
[root]# ebsnvme-id -b /dev/nvme1n1 /dev/xvde
[root]# ebsnvme-id -b /dev/nvme2n1 /dev/xvdf
We have discovered that if the disks are attached after the instance is created, the command will return the full path. If the disks are attached and then the instance is rebooted for example, the command will prune off the /dev/ prefix. This seems to be a problem with whether or not the ebs volumes are present in the instance metadata. I rebooted one of the instances we were working with yesterday and now the output is reflecting this new output:
[root@vlt-us-west-2-production-1106-solr-1 ~]# uptime
13:02:44 up 2 min, 1 user, load average: 0.33, 0.28, 0.11
[root@vlt-us-west-2-production-1106-solr-1 ~]# /sbin/ebsnvme-id -b /dev/nvme2n1 xvde
instance doesn't know abt the ebs volume, it was added later
[root@vlt-eu-central-1-production-2047-solr-6 ~]# curl -m3 http://169.254.169.254/latest/meta-data/block-device-mapping/ami
[root@vlt-us-west-2-production-1106-solr-1 ~]# curl -m3 http://169.254.169.254/latest/meta-data/block-device-mapping/ http://169.254.169.254/latest/meta-data/block-device-mapping ami
[root]# ebsnvme-id -b /dev/nvme0n1 xvda
[root]# ebsnvme-id -b /dev/nvme1n1 /dev/xvde
[root]# ebsnvme-id -b /dev/nvme2n1 /dev/xvdf
We have discovered that if the disks are attached after the instance is created, the command will return the full path. If the disks are attached and then the instance is rebooted for example, the command will prune off the /dev/ prefix. This seems to be a problem with whether or not the ebs volumes are present in the instance metadata. I rebooted one of the instances we were working with yesterday and now the output is reflecting this new output:
[root@vlt-us-west-2-production-1106-solr-1 ~]# uptime
13:02:44 up 2 min, 1 user, load average: 0.33, 0.28, 0.11
[root@vlt-us-west-2-production-1106-solr-1 ~]# /sbin/ebsnvme-id -b /dev/nvme2n1 xvde
instance doesn't know abt the ebs volume, it was added later
[root@vlt-eu-central-1-production-2047-solr-6 ~]# curl -m3 http://169.254.169.254/latest/meta-data/block-device-mapping/ami
[root@vlt-us-west-2-production-1106-solr-1 ~]# curl -m3 http://169.254.169.254/latest/meta-data/block-device-mapping/ http://169.254.169.254/latest/meta-data/block-device-mapping ami
ebs14
ebs2
Subscribe to:
Posts (Atom)
