2021年02月

2021-02-22 周一

微信接口频率限制

使用企业微信中通过手机号获取微信ID的接口报错,超出频率限制

通过手机号获取其所对应的userid

请求方式:POST(HTTPS)
请求地址:https://qyapi.weixin.qq.com/cgi-bin/user/getuserid?access_token=ACCESS_TOKEN

{"mobile":"15168888888"}
<<<<<<<<
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 21 Feb 2021 24:00:00 GMT
Content-Type: application/json; charset=UTF-8
Content-Length: 201
Connection: keep-alive
Error-Code: 45009
Error-Msg: api freq out of limit, hint: [1613886037_148_56f47259fca07048efad5d59a76dee0a], from ip: 115.115.115.115, more info at https://open.work.weixin.qq.com/devtool/query?e=45009

{"errcode":45009,"errmsg":"api freq out of limit, hint: [1613887777_148_56f47259fca07048efad5d59a76aee0b], from ip: 115.115.115.115, more info at https://open.work.weixin.qq.com/devtool/query?e=45009"}
--------
NULL  
[2021-02-21T13:40:37.411709+08:00] EasyWeChat.DEBUG: >>>>>>>>
POST /cgi-bin/message/send?access_token=CqHoppLd7Y_GrbyNgOsKb_twMpfmlg63fQ52xd4GKA9VtQIQSg0zOAUmUptjJ9zZVlQIbmUffYXp-i-KNFlTSanvO5aGznep8m02z_ogLcAibpbgHjvS93qAztTFM33f4nFbkWk9rulXg7rVusTKrgtNsGcYLs1gSayUucGJAnqGtllQPOkQQ6lgHBhE5hPtW1AIqyAKswjUsUghp7Ag9g HTTP/1.1
Host: qyapi.weixin.qq.com
Content-Length: 445
User-Agent: GuzzleHttp/6.5.4 curl/7.70.0 PHP/7.4.9
Content-Type: application/json

官方接口文档:https://work.weixin.qq.com/api/doc/90001/90143/91693

由于应用须拥有指定成员的查看权限,而发送的有些人没有这个权限,所以会报错

image

文档中有说明:

请确保手机号的正确性,若出错的次数较多,会导致1天不可调用

所以原因是多次尝试出错,导致了整个接口都无法调用了,解决方法是尽量不要频繁使用这一个接口。而是将用户已知的ID保存在数据库中,如果数据库中没有或出错再退而求其次的请求这个接口

2021-02-23 周二

Sentry 更新至 21.2.0

ENV 文件配置

 COMPOSE_PROJECT_NAME=sentry_onpremise
SENTRY_EVENT_RETENTION_DAYS=90
# You can either use a port number or an IP:PORT combo for SENTRY_BIND
# See https://docs.docker.com/compose/compose-file/#ports for more
SENTRY_BIND=32707
SENTRY_IMAGE=getsentry/sentry:21.2.0
SNUBA_IMAGE=getsentry/snuba:21.2.0
RELAY_IMAGE=getsentry/relay:21.2.0
SYMBOLICATOR_IMAGE=getsentry/symbolicator:0.3.3

 

事先准备镜像

getsentry/sentry:21.2.0
getsentry/snuba:21.2.0
getsentry/relay:21.2.0
getsentry/symbolicator:0.3.3
postgres:9.6
confluentinc/cp-zookeeper:5.5.0
confluentinc/cp-kafka:5.5.0
yandex/clickhouse-server:20.3.9.70
maxmindinc/geoipupdate:latest
nginx:1.16

启动的容器

root@tabll-server:/# docker-compose up -d
Starting sentry_onpremise_memcached_1            ... done
Starting sentry_onpremise_symbolicator_1         ... done
Starting sentry_onpremise_zookeeper_1            ... done
Starting sentry_onpremise_redis_1                ... done
Creating sentry_onpremise_symbolicator-cleanup_1 ... done
Starting sentry_onpremise_smtp_1                 ... done
Starting sentry_onpremise_clickhouse_1           ... done
Starting sentry_onpremise_postgres_1             ... done
Creating sentry_onpremise_geoipupdate_1          ... done
Starting sentry_onpremise_kafka_1                ... done
Starting sentry_onpremise_snuba-sessions-consumer_1                  ... done
Creating sentry_onpremise_relay_1                                    ... done
Starting sentry_onpremise_snuba-replacer_1                           ... done
Creating sentry_onpremise_snuba-subscription-consumer-transactions_1 ... done
Creating sentry_onpremise_snuba-cleanup_1                            ... done
Starting sentry_onpremise_snuba-api_1                                ... done
Starting sentry_onpremise_snuba-transactions-consumer_1              ... done
Creating sentry_onpremise_snuba-subscription-consumer-events_1       ... done
Starting sentry_onpremise_snuba-outcomes-consumer_1                  ... done
Starting sentry_onpremise_snuba-consumer_1                           ... done
Creating sentry_onpremise_worker_1                                   ... done
Creating sentry_onpremise_cron_1                                     ... done
Creating sentry_onpremise_web_1                                      ... done
Creating sentry_onpremise_ingest-consumer_1                          ... done
Creating sentry_onpremise_subscription-consumer-events_1             ... done
Creating sentry_onpremise_subscription-consumer-transactions_1       ... done
Creating sentry_onpremise_post-process-forwarder_1                   ... done
Creating sentry_onpremise_sentry-cleanup_1                           ... done
Creating sentry_onpremise_nginx_1                                    ... done

更新配置文件需要重新执行以下命令

# 停止所有容器
docker-compose stop
# 重新构建
docker-compose build
# 升级配置
docker-compose run --rm web upgrade
# 启动服务
docker-compose up -d

更新完成!成功接收错误并发送邮件通知

image

2021-02-24 周三

GitLab Runner

 gitlab runner register

sed -i s@/security.ubuntu.com/@/mirrors.aliyun.com/@g /etc/apt/sources.list
sed -i s@/archive.ubuntu.com/@/mirrors.aliyun.com/@g /etc/apt/sources.list

apt update

apt upgrade -y

apt install lsb-release ca-certificates apt-transport-https software-properties-common

add-apt-repository ppa:ondrej/php -y

apt install php8.0

apt install php8.0-bcmath php8.0-mbstring php8.0-xml php8.0-xdebug

apt install composer

composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/

# 取消: composer config -g --unset repos.packagist



# 
apt install vim
vi /etc/gitlab-runner/config.toml

check_interval
sentry_dsn


 

2021-02-25 周四

GitLab Runner 的 Sentry 配置出错

GitLab 的配置文件:

https://gitlab.com/gitlab-org/gitlab-runner/-/blob/master/docs/configuration/advanced-configuration.md#the-runnersdocker-section

sentry_dsn = "https://XXXXXXXXXXXX:XXXXXXXXXXXX@tabll-bug.cpolar.cn/6666"

sentry_dsn 的正确格式应该是上面这样的,使用 Sentry 默认的是会报错 token 为空的

需要点击 Show deprecated DSN 按钮查看老版本的 sentry_dsn

2021-02-26 周五

解决 GitLab 占用 CPU 有些高

最近一段时间,物业电费突然上来了。虽然不排除冬天开空调的能耗高,但是我发现服务器摸起来竟然有些发热,风扇也在转,进去一看 CPU 总占用一直维持在 30+%,而罪魁祸首就是 GitLab 的这个容器,以前也没有出现这个问题,处理器很安静

CPU 消耗的电就是钱啊,于是赶紧看看是什么问题

查看容器日志时,日志一直在循环跳动报错

image

好家伙一直在重试

caller=db.go:1020 component=tsdb msg="Failed to read meta.json for a block during reload. Skipping" dir=/var/opt/gitlab/prometheus/data/01EJJBQERQ6AM2QQPJ9B38QX9G err="invalid character '\\x00' looking for beginning of value

这个问题的官方文档里的解决办法是删了这个 meta.json 所在的整个文件夹:

https://docs.microfocus.com/itom/Data_Center_Automation:2020.11/Nohistoricaldata

但其实我在 管理中心->指标与分析->指标-Prometheus 里面已经把 Prometheus(普罗米修斯) 给关掉了,不需要它执行什么操作,但似乎目前进程还是一直在执行的

于是接下来彻底关闭 Prometheus

编辑 gitlab.rb 配置文件

 vi /etc/gitlab/gitlab.rb

# 设为 False 关闭所有普罗米修斯监控
prometheus_monitoring['enable'] = false

 

image

禁用!保存、配置、重启 三连

gitlab-ctl reconfigure
gitlab-ctl restart

CPU 占用下来了,现在都是 GitLab Runner 的轮询了,也可以考虑调低轮询频率,减少浪费,能省一点是一点

Prometheus 配置文档:

https://docs.gitlab.com/ce/administration/monitoring/prometheus/


唤醒精灵