¿Por qué se están agotando el tiempo de espera de sus solicitudes de etcd?

Cuando el líder recibe una solicitud de escritura, realiza el proceso de copiar la entrada del registro a la mayoría de los nodos del clúster y aplicarla al estado almacenado. ¿Qué situaciones harán que se agote el tiempo de espera de una solicitud?

Utilice ping/traceroute/mtr, ethtool, ifconfig/ip, netstat, tcpdump y otros comandos para obtener datos relevantes.

La capa de aplicación Etcd proporciona indicadores de medición de estadísticas de red entre nodos:

La calidad de la red determina el rendimiento de etcd:

etcd_disk_WAL_fsync_duration_ segundos (que representan datos de retraso de llamadas del sistema fsync para la persistencia del registro WAL)

Y etcd_disk_backend_commit_duration_segundos (retraso de confirmación de transacciones de backend BoltDB).

Si el módulo WAL de etcd se ejecuta en fdatasync durante más de 1 segundo, se generará el registro correspondiente.

Cuando el indicador ETCD_disk_backend_commit_duration_segundos es anormal, significa que el árbol B se está reequilibrando, dividiendo, persistiendo páginas sucias y persistiendo meta durante el proceso de envío de cosas.

Operaciones como las páginas consumen mucho tiempo.

etcd_disk_back end_commit_duration_segundos es alto, etcd_disk_wal_fsync_duration_segundos es normal, lo que indica que el árbol B está en proceso de reequilibrio y división.

Conduciendo a operaciones lógicas de mayor complejidad temporal.

disk_back end_commit_rebalance_duration y disk_back end_commit_spill_duration representan respectivamente las operaciones de reequilibrio y división del árbol B durante el proceso de envío.

Intervalo de asignación que requiere mucho tiempo.

etcd_disk_WAL_fsync_duration_segundos registra la duración de la escritura secuencial de archivos WAL, etcd_disk_back end_commit_duration_segundos registra.

El objetivo es la presentación de todo el asunto, que requiere mucho tiempo.

Antes de que se completen las solicitudes de escritura de etcd 3.2 y etcd 3.3, es necesario actualizar el búfer MVCC y actualizar el bloqueo. Sin embargo, si se produce una solicitud de lectura larga y costosa en el clúster en este momento,

Esto provocará fluctuaciones en la latencia de la solicitud de escritura.

En etcd 3.4, el registrador predeterminado es capnslog y la función de seguimiento de seguimiento solo está habilitada cuando el registrador es zap, por lo que debe configurar - logger=zap.

La función Trace no puede registrar todos los tipos de solicitudes y actualmente solo cubre interfaces comunes como range/put/txn en el módulo MVCC.