SMI

​ zabbix上添加交换机监控记事 ​ 第一次使用zabbix来添加监控华为s5720交换机，根本找不到头绪，像个无头的苍蝇一样的百度来处理，结果都没有任何效果，给自己增加了很多痛苦和心烦，增加不少的白发。 经过询问前任，才发现添加交换机监控的门道，为此我这边记录一下： 第一：先打开zabbix监控画面，选择菜单：configuration--templates,点击create template，并输入名字及属于的groups组，说明，点击update,如下： 第二：添加application(应用集) 第三：添加items(监控项) 在这里添加监控项时就要注意了，这里的key和snmp oid要根据相应的交换机来查询得到其值才能监控到 以uptime为例来说明，key和snmp oid怎么来的，找百度，根本没有什么用处，why? 这么多数据，我要找那个，根本就行不通，我要一个个去测试吗？那就麻烦了，头大了。why? 有办法，看我的操作，还是以uptime为例： key和snmp oid对应的值为sysUpTimeInstance，这里要特别说明一下，我这边是华为s5700的交换机，上zabbix服务器来查询吧，let's go. 先说明一下snmpwalk命令的用法 snmpwalk命令格式``` snmpwalk -v 版本号 -c 密钥 设备ip oid 如

zabbix上添加交换机监控记事 ​ 第一次使用zabbix来添加监控华为s5720交换机，根本找不到头绪，像个无头的苍蝇一样的百度来处理，结果都没有任何效果，给自己增加了很多痛苦和心烦，增加不少的白发。 ​ 经过询问前任，才发现添加交换机监控的门道，为此我这边记录一下： 第一：先打开zabbix监控画面，选择菜单：configuration--templates,点击create template，并输入名字及属于的groups组，说明，点击update,如下： 第二：添加application(应用集) 第三：添加items(监控项) 在这里添加监控项时就要注意了，这里的key和snmp oid要根据相应的交换机来查询得到其值才能监控到 以uptime为例来说明，key和snmp oid怎么来的，找百度，根本没有什么用处，why? 这么多数据，我要找那个，根本就行不通，我要一个个去测试吗？那就麻烦了，头大了。why? 有办法，看我的操作，还是以uptime为例： key和snmp oid对应的值为sysUpTimeInstance，这里要特别说明一下，我这边是华为s5700的交换机，上zabbix服务器来查询吧，let's go. 先说明一下snmpwalk命令的用法 snmpwalk命令格式 snmpwalk -v 版本号 -c 密钥 设备ip oid 如：snmpwalk

zabbix上添加交换机监控记事 ​ 第一次使用zabbix来添加监控华为s5720交换机，根本找不到头绪，像个无头的苍蝇一样的百度来处理，结果都没有任何效果，给自己增加了很多痛苦和心烦，增加不少的白发。 ​ 经过询问前任，才发现添加交换机监控的门道，为此我这边记录一下： 第一：先打开zabbix监控画面，选择菜单：configuration--templates,点击create template，并输入名字及属于的groups组，说明，点击update,如下： 第二：添加application(应用集) 第三：添加items(监控项) 在这里添加监控项时就要注意了，这里的key和snmp oid要根据相应的交换机来查询得到其值才能监控到 以uptime为例来说明，key和snmp oid怎么来的，找百度，根本没有什么用处，why? 这么多数据，我要找那个，根本就行不通，我要一个个去测试吗？那就麻烦了，头大了。why? 有办法，看我的操作，还是以uptime为例： key和snmp oid对应的值为sysUpTimeInstance，这里要特别说明一下，我这边是华为s5700的交换机，上zabbix服务器来查询吧，let's go. 先说明一下snmpwalk命令的用法 snmpwalk命令格式 snmpwalk -v 版本号 -c 密钥 设备ip oid 如：snmpwalk

转载于： https://www.cnblogs.com/dahu-daqing/p/9288157.html nvidia-smi 的定义： 基于 NVIDIA Management Library （NVIDIA 管理库），实现 NVIDIA GPU 设备的管理和监控功能 主要支持 Tesla, GRID, Quadro 以及 TitanX 的产品，有限支持其他的 GPU 产品 所以我们在常见的 NVIDIAGPU 产品上安装完驱动后，都同时安装上 nvidia-smi 管理工具，帮助管理人员通过命令行的方式对 GPU 进行监控和管理。 当我们成功部署了 GRID 软件以后，我们可以通过以下 nvidia-smi 命令实现对 GPU 的管理。 nvidia-smi 会随着 GRID 软件不断的升级，而功能不断的丰富，所以当我们在执行一些复杂的 nvidia-smi 命令时，可能早期的 GRID 版本无法支持这些命令。 以下 nvidia-smi 常用命令行是个人推荐了解的： nvidia-smi 这是服务器上特斯拉 K80 的信息。 上面的表格中： 第一栏的 Fan：N/A 是风扇转速，从 0 到 100% 之间变动，这个速度是计算机期望的风扇转速，实际情况下如果风扇堵转，可能打不到显示的转速。有的设备不会返回转速，因为它不依赖风扇冷却而是通过其他外设保持低温

可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试): 问题: I'm running this command into a shell and get: C:\Users\me>nvidia-smi -L GPU 0: Quadro K2000 (UUID: GPU-b1ac50d1-019c-58e1-3598-4877fddd3f17) GPU 1: Quadro 2000 (UUID: GPU-1f22a253-c329-dfb7-0db4-e005efb6a4c7) But in my code, when I run cuDeviceGetName(.., ID) where ID is the ID given by the nvidia-smi output, the devices have been inverted: GPU 0 becomes Quadro 2000 and GPU 1 becomes Quadro K2000. Is this an expected behavior or a bug ? Does anyone know a workaround to make nvidia-smi get the 'real' ID of GPUs ? I could use the UUID to get

zabbix上添加交换机监控记事 第一：先打开zabbix监控画面，选择菜单：configuration--templates,点击create template，并输入名字及属于的groups组，说明，点击update,如下： 第二：添加application(应用集) 第三：添加items(监控项) 在这里添加监控项时就要注意了，这里的key和snmp oid要根据相应的交换机来查询得到其值才能监控到 以uptime为例来说明，key和snmp oid怎么来的，找百度，根本没有什么用处，why? 这么多数据，我要找那个，根本就行不通，我要一个个去测试吗？那就麻烦了，头大了。why? 有办法，看我的操作，还是以uptime为例： key和snmp oid对应的值为sysUpTimeInstance，这里要特别说明一下，我这边是华为s5700的交换机，上zabbix服务器来查询吧，let's go. 先说明一下snmpwalk命令的用法 snmpwalk命令格式 snmpwalk -v 版本号 -c 密钥 设备ip oid 如：snmpwalk -v 2c -c luxshare 10.98.18.10 system 这里2c为snmp v2版本，luxshare为交换机的snmp密钥，ip为需要查看的设备ip地址 system为设备的oid基本命令 再确定环境及操作

敖小剑，蚂蚁金服高级技术专家，十七年软件开发经验，微服务专家，Service Mesh 布道师，ServiceMesher 社区联合创始人。 本文内容整理自 8 月 11 日 Service Mesher Meetup 广州站主题演讲，完整的分享 PPT 获取方式见文章底部。 前言 标题“Service Mesh发展趋势(续)”中的“续”是指在今年5月底，我在 CloudNative Meetup上做了一个“ Service Mesh发展趋势：云原生中流砥柱 ”的演讲，当时主要讲了三块内容：Service Mesh 产品动态、发展趋势、与云原生的关系。后来有同学反应希望部分感兴趣的内容能讲的更深一些，所以今天将继续“Service Mesh 发展趋势”这个话题。 今天给大家分享的内容有部分是上次演讲内容的深度展开，如社区关心的 Mixer v2 以及最近看到的一些业界新的技术方向，如 web assembly 技术，还有产品形态上的创新，如 google traffic director 对 Service Mesh 的虚拟机形态的创新支持。 在 Service Mesh 出道四年之际，也希望和大家一起带着问题来对 Service Mesh 未来的发展进行一些深度思考。 在正式开始分享之前，让我们先轻松一下，下面是最近流行的梗，各种灵魂拷问： 我们今天的分享内容，将效仿上面的方式

浅谈 docker 挂载 GPU 原理 基础知识 隔离（Namespace） 限制（Cgroup） 挂载 GPU 实验 使用 nvidia-docker2 原生 docker 使用 GPU nvidia-docker 原理 安装 Nvidia driver 驱动 Nvidia driver CUDA Toolkit 浅谈 docker 挂载 GPU 原理 基础知识 对于 Docker 等大多数 Linux 容器来说，Cgroups 技术是用来制造约束的主要手段，而 Namespace 技术则是用来修改进程视图的主要方法。 Docker 启动的只是一个进程而已，而不是别的。 参考： DOCKER基础技术：LINUX NAMESPACE（上） DOCKER基础技术：LINUX NAMESPACE（下） 06 | 白话容器基础（二）：隔离与限制 隔离（Namespace） 写代码调用 clone 的时候，传入 CLONE_NEWPID/CLONE_NEWNS/CLONE_NEWUTS/CLONE_NEWNET/CLONE_NEWIPC 等就可以启动一个被隔离的进程 简单来说 Namespace 是一个障眼法： PID Namespace Mount 只能看到当前 Namespace 中的挂载点信息 UTS IPC Network 只能看到当前 Namespace 中的网络设备 User

H3C交换机： 型号+版本（snmpget）：SNMPv2-SMI::mib-2.47.1.1.1.1.2.2 型号（snmpget）：SNMPv2-SMI::mib-2.47.1.1.1.1.13.212 序列号（snmpget）：SNMPv2-SMI::mib-2.47.1.1.1.1.11.2 光模块序列号（snmpwalk）：SNMPv2-SMI::mib-2.47.1.1.1.1.11 来源： 51CTO 作者： wq2010feng 链接： https://blog.51cto.com/keefe/2449385

敖小剑，蚂蚁金服高级技术专家，十七年软件开发经验，微服务专家，Service Mesh 布道师，ServiceMesher 社区联合创始人。 本文内容整理自 8 月 11 日 Service Mesher Meetup 广州站主题演讲，完整的分享 PPT 获取方式见文章底部。 前言 标题“Service Mesh发展趋势(续)”中的“续”是指在今年5月底，我在 CloudNative Meetup上做了一个“ Service Mesh发展趋势：云原生中流砥柱 ”的演讲，当时主要讲了三块内容：Service Mesh 产品动态、发展趋势、与云原生的关系。后来有同学反应希望部分感兴趣的内容能讲的更深一些，所以今天将继续“Service Mesh 发展趋势”这个话题。 今天给大家分享的内容有部分是上次演讲内容的深度展开，如社区关心的 Mixer v2 以及最近看到的一些业界新的技术方向，如 web assembly 技术，还有产品形态上的创新，如 google traffic director 对 Service Mesh 的虚拟机形态的创新支持。 在 Service Mesh 出道四年之际，也希望和大家一起带着问题来对 Service Mesh 未来的发展进行一些深度思考。 在正式开始分享之前，让我们先轻松一下，下面是最近流行的梗，各种灵魂拷问： 我们今天的分享内容，将效仿上面的方式