Skip to content

Conversation

@arista-hpandya
Copy link
Contributor

@arista-hpandya arista-hpandya commented Feb 10, 2025

What I did

  • Added the DEBUG_DROP_MONITOR table definition to sonic-swss-common.

Why I did it

This change is a prerequisite for another PR (sonic-net/sonic-swss#3509) that relies on using the DEBUG_DROP_MONITOR table in the orchagent for persistent drop counter monitoring.

How I verified it
NA

Details if related

This PR only adds the table definition. The logic to read, process, and act upon the data in this table is implemented in a PR linked above.

Fixes #972
HLD: sonic-net/SONiC#1912

@mssonicbld
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

FengPan-Frank
FengPan-Frank previously approved these changes Feb 12, 2025
Copy link
Contributor

@FengPan-Frank FengPan-Frank left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@arista-hpandya arista-hpandya marked this pull request as draft February 18, 2025 17:41
@arista-hpandya arista-hpandya marked this pull request as ready for review May 15, 2025 18:36
@mssonicbld
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@mssonicbld
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@arista-hpandya
Copy link
Contributor Author

/azpw run Azure.sonic-swss

@mssonicbld
Copy link
Collaborator

/AzurePipelines run Azure.sonic-swss

@azure-pipelines
Copy link

No pipelines are associated with this pull request.

vmittal-msft
vmittal-msft previously approved these changes Jun 17, 2025
@vmittal-msft
Copy link

@arista-hpandya please rebase.

@mssonicbld
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@arista-hpandya
Copy link
Contributor Author

The vstest failure is unrelated to the change, can we override the warnings and go ahead with the merge?

dash/test_dash_acl.py: 12 warnings
  /usr/local/lib/python3.10/dist-packages/_pytest/unraisableexception.py:65: PytestUnraisableExceptionWarning: Exception ignored in: <function ApplDbValidator.__del__ at 0x75b5f2665a20>
  
  Traceback (most recent call last):
    File "/agent/_work/1/s/sonic-swss/tests/conftest.py", line 184, in __del__
      neighbors = self.get_keys(self.NEIGH_TABLE)
    File "/agent/_work/1/s/sonic-swss/tests/dvslib/dvs_database.py", line 134, in get_keys
      table = swsscommon.Table(self.db_connection, table_name)
    File "/usr/lib/python3/dist-packages/swsscommon/swsscommon.py", line 3169, in __init__
      _swsscommon.Table_swiginit(self, _swsscommon.new_Table(*args))
  RuntimeError: Unable to connect to redis (unix-socket) - No such file or directory(1): Cannot assign requested address
  
  Enable tracemalloc to get traceback where the object was allocated.
  See https://docs.pytest.org/en/stable/how-to/capture-warnings.html#resource-warnings for more info.
    warnings.warn(pytest.PytestUnraisableExceptionWarning(msg))


@vmittal-msft
Copy link

Please rebase and re-run pipeline.

@mssonicbld
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@arista-hpandya
Copy link
Contributor Author

The failures are because of an outdated libyang version:

libyang-dev depends on libyang3 (= 3.12.2-1); however:
Package libyang3 is not installed.

Enhancement to libyang3 is being tracked here: sonic-net/sonic-buildimage#22385

Since this particular change is harmless and irrelevant to the failure could we merge this in? This is a dependency of sonic-net/sonic-swss#3509 and its waiting on this being merged.

cc: @vmittal-msft

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@mssonicbld
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@mssonicbld
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@mssonicbld
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@vmittal-msft
Copy link

@arista-hpandya please resolve conflicts.

@mssonicbld
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@mssonicbld
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@arista-hpandya
Copy link
Contributor Author

@vmittal-msft the semgrep needs maintainer approval without which it gets stuck, all tests have passed and this can be merged:

image

@vmittal-msft
Copy link

@rlhui @yxieca please help merge.

@arista-hpandya
Copy link
Contributor Author

arista-hpandya commented Aug 27, 2025

@vmittal-msft @rlhui @yxieca All tests have passed could we merge this please, thanks!

@rlhui rlhui merged commit f0e88e0 into sonic-net:master Aug 27, 2025
15 checks passed
prsunny pushed a commit to sonic-net/sonic-swss that referenced this pull request Oct 6, 2025
…onitoring feature (#3509)

* Add support for configurable debug drop monitoring feature

Note: This change depends on sonic-net/sonic-swss-common#971
Fixes #3501
HLD: sonic-net/SONiC#1912

What I did

Added logic to read configuration from the DEBUG_DROP_MONITOR table.
Added logic to register persistent alerts when the conditions are met.
Added logic to toggle the feature off if desired on a per-counter level.
Why I did it
To implement the persistent drop counter monitoring feature which allows users to configure thresholds for drop counters and register alerts when persistent drops are detected.

How I verified it

Existing unit tests were run using make check to ensure no functionality was affected.
New unit tests have been added to verify the functionality.
Manual testing was performed on a SONiC switch to verify that the orchagent correctly reads the configuration, generates alerts when thresholds are met, and can be toggled off/on.
Janetxxx pushed a commit to Janetxxx/sonic-swss that referenced this pull request Nov 10, 2025
…onitoring feature (sonic-net#3509)

* Add support for configurable debug drop monitoring feature

Note: This change depends on sonic-net/sonic-swss-common#971
Fixes sonic-net#3501
HLD: sonic-net/SONiC#1912

What I did

Added logic to read configuration from the DEBUG_DROP_MONITOR table.
Added logic to register persistent alerts when the conditions are met.
Added logic to toggle the feature off if desired on a per-counter level.
Why I did it
To implement the persistent drop counter monitoring feature which allows users to configure thresholds for drop counters and register alerts when persistent drops are detected.

How I verified it

Existing unit tests were run using make check to ensure no functionality was affected.
New unit tests have been added to verify the functionality.
Manual testing was performed on a SONiC switch to verify that the orchagent correctly reads the configuration, generates alerts when thresholds are met, and can be toggled off/on.
balanokia pushed a commit to balanokia/sonic-swss that referenced this pull request Nov 17, 2025
…onitoring feature (sonic-net#3509)

* Add support for configurable debug drop monitoring feature

Note: This change depends on sonic-net/sonic-swss-common#971
Fixes sonic-net#3501
HLD: sonic-net/SONiC#1912

What I did

Added logic to read configuration from the DEBUG_DROP_MONITOR table.
Added logic to register persistent alerts when the conditions are met.
Added logic to toggle the feature off if desired on a per-counter level.
Why I did it
To implement the persistent drop counter monitoring feature which allows users to configure thresholds for drop counters and register alerts when persistent drops are detected.

How I verified it

Existing unit tests were run using make check to ensure no functionality was affected.
New unit tests have been added to verify the functionality.
Manual testing was performed on a SONiC switch to verify that the orchagent correctly reads the configuration, generates alerts when thresholds are met, and can be toggled off/on.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

[Feature] Add DEBUG_DROP_MONITOR table in schema.h

5 participants