调试alertmanager的坑

最近遇到一些问题，想要调试alertmanager。结果遇到了不少的坑点，主要也是过度关注文档导致的。

官方文档编译方式

下面是官方文档给的编译方式。直接make build就好

$ mkdir -p $GOPATH/src/github.com/prometheus
$ cd $GOPATH/src/github.com/prometheus
$ git clone https://github.com/prometheus/alertmanager.git
$ cd alertmanager
$ make build

这个是可以编译成功的，最后用goland attach进程的方式进行调整，发现无法和源码对应。导致调试失败了。
goland的attach方式其实不能算是一个合理的调试方式。了解go的调试方式，其实是需要编译一个可调试版本的，这个和c语言很想，需要加编译参数来调试。之所以使用这个方式去调试，是因为这个方式可以调试prometheus，也可以调试grafana。只是会有偶尔的变量看不到值，大部分是可用的。没想到在alertmanager是行不通的。

添加编译选项

工程的编译是通过makefile来做的。我的思路是通过在makefile编译的信息中加入调试信息，然后再进行编译。

make build -n

本来预期的是希望是看到go开头的编译命令，结果却不是。

echo ">> building binaries"
GO111MODULE=on /Users/codes/bin/promu build  --prefix /code/alertmanager

编译命令竟然不是go，而是promu。这个是prometheus提供的编译工具。只能通过–help看看他的参数。

usage: promu build [<flags>] [<binary-names>...]

Build a Go project

Flags:
  -h, --help                 Show context-sensitive help (also try --help-long and --help-man).
  -c, --config=".promu.yml"  Path to config file
  -v, --verbose              Verbose output
      --cgo                  Enable CGO
      --prefix=PREFIX        Specific dir to store binaries (default is .)

Args:
  [<binary-names>]  List of binaries to build

结果竟然是不支持！
这个就很麻烦了。他给的编译方式竟然不支持去编译一个调试版本。

自己编译

之所以一直看官方的文档，主要是因为这个工程相对是比较大的工程，而且有makefile脚本来编译，其中做了一些事情，最麻烦的是他用promu来编译，你都不知道这个方式到底是做了什么事情，黑盒的东西太多了。
我仔细看了一遍工程，发现他本身就是go的工程，那么go的编译方式必须有用的，只不过可能编译出的版本是一个没有web界面的这种或者是有其他的功能缺失的情况，为什么这么想主意是和java的maven功能做类比，maven的编译和打包是分开的。打包最后的才是产品形态，编译可能的结果只是把java文件编译打了jar包（springboot的当然有jar就可以了，普通的java程序就不是了）。
于是把整体工程导入goland。找到main方法，右击debug。
竟然是可以的，直接就可以调试了。

小结

自己做了一些操作，在最终看来似乎是绕了远路。折腾一圈，结果还是最简单的方式可以解决问题。但是思路上是可以推敲的。首先，我们接触一个不了解的工程，文档上有编译指令。正常的选择都是依靠编译指令去做，如果有需求，在修改编译指令。很不好的是alertmanager是使用了promu，是另外一个黑盒工具，这个才造成了麻烦，不知道他里面做了什么，最后没有办法才进行尝试直接用go编译。
这里可以做个类比，例如你可以使用maven工程编译一个java工程，其实只要用javac就可以，如果上来不学mvn install，非得自己javac来做，结果也是成功的，但是比起命令，就不是什么明智的选择了。
扩展开来说，应该在两个方面注意，一个是工具的功能，例如promu说不定有调试选项，虽然结果证明他只是编译。另外一个需要注意的问题的本质，就是会使用go去编译一个调试版本。解决问题的思路大概如此，如果说万一上面的尝试，发现go编译出一个后台程序，他是前后台分离的，那就需要我们补全promu的功能，或者我们就使用编译的后端程序，解决后端的问题，需要前端触发的话，可以考虑用curl来替代触发，不过这个不能算是一个好的方案，需要根据实际的情况来判断我们需要探索的范围。一般是做到满足需求即可，使用二八原理解决问题。