partial write: max-values-per-tag limit exceeded
这个问题可能会出现较早的版本，有些版本限定了tag的数目，不能超过10w。过多tag会导致的问题在前面的文章有提到过。这里需要强调的是，不同的存储策略也会导致tag的重复，所以在设计metric的时候就应该考虑清楚适当的存储时间。
partial write: points beyond retention policy dropped=2
比如写入数据的数据库的保存rp是10天，而你批量插入的数据点中有时间戳在此范围之外的，就会导致这个错误。这里引申一下，假设批量插入10个点，遍历到第4个点时出现了错误，是否会影响接下来point的写入呢？这个我暂时没有做验证，但就与其他使用者的讨论，则是有可能的。所以在测试代码时，必须解决每一个抛出的问题。
数值0不被识别？
之前上报的业务数据中，有一项指标是用户意外掉线的原因(reason)。这个上报来的数据是0，1，2这样的整数。上报代码是通过python完成的。但是在chronograf的图形界面输入query语句，在where后面添加reason = 0 and ...会查询不到数据。而检视原始数据是有上报这样的信息的。
使用curl的方式检测是正常的。
数据写入量过多时，出现大量tcp连接处于wait状态
比如在使用golang的第三方库包向influxdb写入数据时，出现了这样的情况，后来查看了下源码，把创建的http client的keepalive关闭会解决该问题。并且在关闭后也并未出现明显影响写入性能的情况。
另外虽然influxdb自己拥有很强的并发写入能力，但网站文档上的数字，只是他们在极端情况下的数据。就我们平常的使用是不太好能达到别人那个水平的。这里可以推荐打开influxdb 的udp配置，然后使用其line protocol以udp包的形式写入数据。实测写入性能提升得非常明显。
有疑问加站长微信联系（非本文作者）
