[asterisk-bugs] [JIRA] (ASTERISK-29292) removing extension from pjsip does not remove it from the prometheus metrics without asterisk restart

[Ugis Ulbiks (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-29292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ugis Ulbiks updated ASTERISK-29292:
-----------------------------------

    Description: 
We had some unused extensions that have not been removed. By removing them and performing a reload they still show up in the Prometheus metrics.
I tried to reload with:

{code}
asterisk -rx 'pjsip reload'
asterisk -rx 'dialplan reload'
asterisk -rx 'reload'
{code}

For example, the extension 666 was removed from /etc/asterisk/pjsip.conf .
Afterwards a reload was performed.

The metrics for the extension are still there:
{code}
# curl -s https://asterisk.example.local:8089/metrics | grep 666           
asterisk_endpoints_state{eid="00:50:56:9f:f5:39",id="PJSIP/666",tech="PJSIP",resource="666"} 1
asterisk_endpoints_channels_count{eid="00:50:56:9f:f5:39",id="PJSIP/666",tech="PJSIP",resource="666"} 0
{code}

The metrics disappear after asterisk service restart. However, that is not a good solution as a restart will terminate any active calls, also we use ansible to do perform all configuration changes which means handlers are used, so we would like to avoid an asterisk restart handler for the reason mentioned above.

  was:
We had some unused extensions that have not been removed. By removing them and performing a reload they still show up in the Prometheus metrics.
I tried to reload with:

{code:bash}
asterisk -rx 'pjsip reload'
asterisk -rx 'dialplan reload'
asterisk -rx 'reload'
{code}

For example, the extension 666 was removed from /etc/asterisk/pjsip.conf .
Afterwards a reload was performed.

The metrics for the extension are still there:
{code:bash}
# curl -s https://asterisk.example.local:8089/metrics | grep 666           
asterisk_endpoints_state{eid="00:50:56:9f:f5:39",id="PJSIP/666",tech="PJSIP",resource="666"} 1
asterisk_endpoints_channels_count{eid="00:50:56:9f:f5:39",id="PJSIP/666",tech="PJSIP",resource="666"} 0
{code}

The metrics disappear after asterisk service restart. However, that is not a good solution as a restart will terminate any active calls, also we use ansible to do perform all configuration changes which means handlers are used, so we would like to avoid an asterisk restart handler for the reason mentioned above.


> removing extension from pjsip does not remove it from the prometheus metrics without asterisk restart
> -----------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-29292
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29292
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: . I did not set the category correctly.
>    Affects Versions: 18.1.0
>         Environment: OpenBSD 6.8
> asterisk-18.1.1
>            Reporter: Ugis Ulbiks
>
> We had some unused extensions that have not been removed. By removing them and performing a reload they still show up in the Prometheus metrics.
> I tried to reload with:
> {code}
> asterisk -rx 'pjsip reload'
> asterisk -rx 'dialplan reload'
> asterisk -rx 'reload'
> {code}
> For example, the extension 666 was removed from /etc/asterisk/pjsip.conf .
> Afterwards a reload was performed.
> The metrics for the extension are still there:
> {code}
> # curl -s https://asterisk.example.local:8089/metrics | grep 666           
> asterisk_endpoints_state{eid="00:50:56:9f:f5:39",id="PJSIP/666",tech="PJSIP",resource="666"} 1
> asterisk_endpoints_channels_count{eid="00:50:56:9f:f5:39",id="PJSIP/666",tech="PJSIP",resource="666"} 0
> {code}
> The metrics disappear after asterisk service restart. However, that is not a good solution as a restart will terminate any active calls, also we use ansible to do perform all configuration changes which means handlers are used, so we would like to avoid an asterisk restart handler for the reason mentioned above.



--
This message was sent by Atlassian JIRA
(v6.2#6252)