https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092020-06-07T18:40:18ZOpen Source Mobile Communicationslibosmocore - Feature #4591: Export FSM states and statistics with countershttps://projects.osmocom.org/issues/4591?journal_id=185852020-06-07T18:40:18Zlaforge
<ul></ul><p>On Sun, Jun 07, 2020 at 02:40:30AM +0000, ipse [REDMINE] wrote:</p>
<blockquote>
<p>Working on borken stats export and thinking about adding monitoring to OsmoSTP and MGCP code, I realized<br />that a lot of useful information can be acquired from FSMs if they supported generic statistics export.</p>
</blockquote>
<p>Intresting idea. You most likely know that the FSMs already are auto-added to the CTRL and VTY interface<br />in a generic way, but currently I think only their state as well as the current timer+timeout (if any) are<br />exported?</p>
<blockquote>
<ol>
<li>Counters for transitions to/from states (per state) and received events (per event). Useful for short-living FSMs like lchan's.</li>
</ol>
</blockquote>
<p>how would you handle such counters? Normally, the approach would be to allocate a new set of<br />counters for every lchan, but then if that lchan gets destroyed, you'd loose the history...</p> libosmocore - Feature #4591: Export FSM states and statistics with countershttps://projects.osmocom.org/issues/4591?journal_id=185912020-06-07T20:08:51Zipse
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/18591/diff?detail_id=30779">diff</a>)</li></ul><p>laforge wrote:</p>
<blockquote>
<p>On Sun, Jun 07, 2020 at 02:40:30AM +0000, ipse [REDMINE] wrote:</p>
<blockquote>
<p>Working on borken stats export and thinking about adding monitoring to OsmoSTP and MGCP code, I realized<br />that a lot of useful information can be acquired from FSMs if they supported generic statistics export.</p>
</blockquote>
<p>Intresting idea. You most likely know that the FSMs already are auto-added to the CTRL and VTY interface<br />in a generic way, but currently I think only their state as well as the current timer+timeout (if any) are<br />exported?</p>
</blockquote>
<p>Yes. Plus general information like parent and child FSMs, IDs, list of events, etc.</p>
<p>My idea is mostly about exporting the gauges and counters to <code>statsd</code> but they can be used to enrich the VTY output as well, of course.</p>
<blockquote><blockquote>
<ol>
<li>Counters for transitions to/from states (per state) and received events (per event). Useful for short-living FSMs like lchan's.</li>
</ol>
</blockquote>
<p>how would you handle such counters? Normally, the approach would be to allocate a new set of<br />counters for every lchan, but then if that lchan gets destroyed, you'd loose the history...</p>
</blockquote>
<p>I was rather thinking about linking state transition counters to the FSM classes, not instances - so that they survive FSM instance death. But now I'm not sure this is a correct approach.</p>
<p>lchan's and timeslots are actually quite long-leaving FSMs. lchan's live while the OML link is up, and timeslots are never destroyed at all. At the same time, we want to see stats <em>at least</em> on the per-BTS granularity. Better yet - even with timeslot/subslot granularity in some cases. Which means these stats should be at the FSM instance level.</p>
<p>re: losing history<br />At least in our environment, we don't care too much about losing history for long-living FSMs like lchan's because we export it to <code>statsd</code> and store/analyze externally. And there we have a full history, including from previous app instances. From our perspective, VTY is useful for digging deeper once we notice something wrong in the exported stats. So having a full history in VTY is not a goal in our use case - it's more important for us to be able to get access to detailed internal status/state via VTY to assist debugging.</p> libosmocore - Feature #4591: Export FSM states and statistics with countershttps://projects.osmocom.org/issues/4591?journal_id=217122021-03-24T12:34:10Zlaforge
<ul><li><strong>Category</strong> set to <i>libosmocore</i></li></ul>