Forum Discussion

MoFabricIoT's avatar
MoFabricIoT
Regular Visitor
27 days ago

Anomaly Detector is disabled

Hello, I have a big Table in which we have our TimeSeries data from various devices. Since not every device sends the same data we have a big schema of numeric columns that are not filled for every deviceId.

Is that the reason why there is no Anomaly Detector in my EventHouse? In the schema I can see that columns for the data are int or real. Some columns are string, but that shoudn't be the reason, right?

Has anyone faced the same issue?

eventhouse
kql database

5 Replies

  • ShivekMaharaj's avatar
    ShivekMaharaj
    Icon for Memorable Member rankMemorable Member
    26 days ago

    Hi MoFabricIoT​,

    The empty numeric values across different devices should not by themselves be the reason the Anomaly Detector is disabled.

    The current Anomaly Detection documentation says the input table must contain all three of these column types:

    • a numeric value column
    • a datetime column
    • a string column

    So your int/real columns satisfy the numeric requirement, and having additional string columns is fine.

    I would check the timestamp column next. Even if it contains timestamp-looking values, make sure its actual KQL type is datetime rather than string, long or dynamic. You can quickly inspect the table schema with:

    YourTable | getschema

    The detector configuration uses the numeric column as Value to watch, a string column for Group by, and a datetime column for Timestamp.

    If you already have all three types in the table and it is still disabled, I would then check the other Anomaly Detector prerequisites, particularly the Preview feature setting and Python support on the Eventhouse.

    One other point: the feature is currently Preview, and Microsoft documents this schema requirement as a current limitation. I would not redesign the wide IoT table purely because some numeric fields are null for devices that do not emit those measurements.

    AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.

  • v-sathmakuri's avatar
    v-sathmakuri
    Icon for Community Support rankCommunity Support
    22 days ago

    Hi MoFabricIoT​ ,

    Thank you for reaching out to fabric community.

    Could you review the suggestion provided above and let us know if you have any additional questions, we are happy to address. 

     Thanks!!

    • MoFabricIoT's avatar
      MoFabricIoT
      Regular Visitor
      15 days ago

      Hi v-sathmakuri​ ,

      thanks for your support. Unfortunately this doesn't help me. I have all the three data types in my schema and the shared link only provides help when being in the Anomaly Detection. My Problem is that I don't get in there.

      regards

      Moritz

  • v-sathmakuri's avatar
    v-sathmakuri
    Icon for Community Support rankCommunity Support
    7 days ago

    Hi MoFabricIoT​ ,

    If the Anomaly Detection option itself is missing, then the issue is probably not related to the column data types.

    Could you verify that the Eventhouse/KQL database and the specific table satisfy the prerequisites for the Anomaly Detection experience, and that the feature is currently available and enabled for your Fabric environment or capacity? A wide table with nullable numeric columns should not, by itself, stop the entry point from appearing.

    If possible, could you share a screenshot of the Eventhouse/table UI where you expect the Anomaly Detection option to appear? That would help determine whether this is a UI/feature availability issue rather than a schema issue.

    Thanks!!