从宿主机获得Docker内部IP
在Docker内部获取IP
Docker内部里面，ipconfig/ip 等命令是无法使用的，正确的命令是
$ hostname -I
172.24.116.11在宿主机获得Docker的IP
假设你已经有了一个Docker，ID是f864187a2406
$ docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' f864187a2406
172.24.116.11
$ docker inspect --format '{{ .NetworkSettings.IPAddress }}' f864187a2406
172.24.116.11
$ docker inspect f864187a2406 | egrep -e "(IPAddress|Id)"
"Id": "f864187a24065636dc0cf9e87bdf2971fea27d4014cf981eaac6b971506b2776",
"deployId": "8747",
"SecondaryIPAddresses": null,
"IPAddress": "172.24.116.11",
"IPAddress": "172.24.116.11",Windows平台下代替鲁大师查看硬件配置信息的工具
Windows平台下替代鲁大师查看电脑硬件配置信息的工具，目前推荐HWinfo64和Speecy，二者目前都是免费，且都可以通过Google搜索到。
简单试用了下，来说了二者的区别吧。
- HWinfo64官网有免安装版本，解压以后直接就可以运行。统计的信息较全，尤其是能统计电池相关信息；
- Speecy展示的结果更加直接一些，尤其是对于硬盘信息的显示，以及硬盘每项指标对应健康状态的评估。
在Linux下转换unix时间戳
在Linux下转换unix时间戳是非常容易的事情, 用date命令就可以实现.
$ date -d @1576806092
Fri Dec 20 09:41:32 CST 2019Grafana内置的运算函数
Grafana内置了如下运算函数， 相信不少人跟我一样，对于count和sum傻傻分不清楚，下面详细介绍一下。
| 运算函数 | 说明 |
| count | 数据点数（在单位时间里去抓取了几次metric），一般很少用，例如，配置了Prometheus每隔15s去抓取1次数据，在1分钟内的count就是5，5分钟内的count就是21 |
| sum | 这个metric获取的所有value的总和，例如， 配置了Prometheus每隔15s去抓取1次数据，在1分钟内的抓取到的这个metric对应value分别是3,4,5,4,2，那么1分钟内的sum就是3+4+5+4+2 |
| avg | 平均值，相当于sum/count |
| max | 最大值 |
| min | 最小值 |
| last | 最后一个值 |
| diff | 起始值和最终值之间的差异 |
| percent_diff | 起始值与最终值之差/起始值与最终值的平均值* 100 |
| count_not_null | value不为空的count |
对于count的理解稍微有些难度。count通常是指(单位时间内的)metric数据的数量(例如，我们有个名为qps的metric，在过去1分钟内，我们每隔15s去获取1次qps的值，那么过去1分钟的count(qps)就是5)，如果数据源是ElasticSearch，这个count通常指单位时间内的日志条目(日志数量)，这样对于统计访问者/流量是比较有用的。但是如果数据源是Prometheus的的话，由于Prometheus的配置文件指定了每隔多久去抓取1次数据，因此count的数量比较固定。
Read MorePrometheus的label处理
Prometheus能否在查询的时候对label进行2次处理呢？答案是可以的。Prometheus提供了一系列函数可以在Query的时候进行二次处理，本文要介绍的函数是label_replace()。
我们都知道，在 Prometheus 的配置文件里，不论targets里的ip是否带了:9100，最终形成的instance里面都会给你带上这个端口，形成像192.168.1.1:9100这样的格式。这个 instance本身就是一个 Prometheus 内置的label（这里指192.168.1.1:9100）。今天我们演示一下把讨厌的:9100去掉。
虽然我们也可以使用Variables功能来对instance进行正则化处理（如下图），但是处理以后的结果，在dashboard里面无法选中单个主机。因此这种方法是有bug的（不推荐使用）。
最近对视频编码的一些研究心得
从某知名视频网站下载了一个小视频, 1080P 25帧的, 比特率是2600kbps, 格式为H.264/AVC, 视频长度为5分钟, 才98M的体积. 某天心血来潮想把它转换为H.265/HEVC格式的视频, 试了无数次才发现, 用现有的工具, 转换出来的H.265/HEVC格式的视频, 体积比它大的, 可能还没有它清晰, 体积比它小的, 清晰度就差更多了. 传说中的H.265/HEVC的优势哪里去了?
1, 一些专有名词
Constant QP (CQP)
Constant Quantization Parameter, 恒定量化编码模式, 也称 CQ (constant quantizer)模式, 英文解释为The quantization parameter defines how much information to discard from a given block of pixels (a Macroblock), 此参数控制每个宏块(Macroblock)的压缩量. 此值越大, 表示要丢弃的Macroblock就越多(压缩率越大), 视频体积越小, 同时视频质量越差. 一般是用GPU转码时, 才会有CQP选项. 不建议使用此模式, 原因如下
Setting a fixed QP means that the resulting bitrate will be varying strongly depending on each scene’s complexity, and it will result in rather inefficient encodes for your input video. You may waste space and you have no control of the actual bitrate.
Average Bitrate (ABR)
平均比特率, 这个不多说了. 不建议使用此模式. 老外的分析如下
Read MoreOne of the main x264 developers himself says you should never use it. Why? As the encoder doesn’t know exactly what’s ahead in time, it will have to guess how to reach that bitrate. This means that the rate itself will vary, especially at the beginning of the clip, and at some point reach the target. Especially for HAS-type streaming, this leads to huge quality variations within short segments.